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Dear Sir: 

DECLARATION OF PRIOR INVENTION UNDER 37 C.F.IL SL131 

I, Bret A. Lowensohn, hereby declm*e that : 

1, I am one of the co-inventors named in the above-identified application, andl amnow 
the record owner by assignment of the entire right, title and interest in that application. 

2. During the years 2000 and 2001 when the events recited below occurred, I was 
employed by Kaiser Foundation Hospitals (hereinafter "KFET'), a nonprofit, public-benefit 
corporation that owns and operates community hospitals in California, Oregon, and Hawaii; 
owns outpatient facilities in several states; provides or arranges hospital services; and sponsors 
charitable, educational, and research activities. 

3. During my employment by KPH in the years 2000 and 2001, I served as Director, Advanced 
Technologies for Kaiser Foundation Heahh Plan / Hospitals, 393 E. Walnut, Pasadena, CA . 
During this period, I directed, and participated in the "Biometric Authentication and Roaming 
Badge Technology Project" (hereinafter the "BARB Project") conducted by KFH which resuked 
in the design, development, construction, testing and operation of badge-based authentications 
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system described in the above-identified patent application which I will hereinafter refer to as the 
"BARB Pilot System." I have direct personal knowledge of the facts set forth in this declaration. 

4. The BARB Pilot System is described and claimed in the above-identified pateiit 
application. That system consisted of an administration subsystem (shown in the block diagram 
Fig. 5 of the application) that communicated with one or more "BARB Badges" (shown in the 
block diagram Fig. 2 of the application) by way of one or more "BARB Base" stations (shown in 
block diagram Fig, 3 of the application). 

5. The BARB Pilot System described and claimed in the application was conceived in its 
entirety before Januaiy 26, 2001 as shown by Exhibits B, C and D which are all dated on or 
before that date. Exhibits B, C and D formed the basis for, and contain substantially the same 
technical disclosure as, the above-identified patent appUcation as more fiiUy detailed in 
paragraph 15, below, 

7. Exhibit A is a true copy of the "CONTRACTING SERVICE AGREEMENT" entered 
into between KPH and a first contractor, Saflink Corporation, on Septemba- 22, 2000 (see '-Date 
of Issue" on page 2 of the AGREEMENT). Pursuant to this agreement, Saflink developed the 
software for the administration subsystem for the BARB Pilot System in accordance with the 
requirements and functional specifications provided to Saflink by KFH. As provided in this 
AGREEMENT, Saflink Corporation was to complete and deliver the software for the 
administrative subsystem, along with system documentation, on or before January 31, 200L 

8. Exhibit B is a true copy of Version 1.2 of the "System Functional Specification, 
Biometric Authentication and Roaming Badge Technology Project" dated "26 January 2001" 

. that describes the administrative subsystem software supplied by Saflink. The Function 
Specification, Exhibit B, was used as the source of the major portion of the, disclosure found in 
the abovernoted application and the correspondence between the two disclosures may be verified 
by comparing the drawing figures in the above-noted application with the corresponding drawing 
figures found in the fimctional specification as indicated in paragraph 15 below. 

9. Exhibit C is a true copy of a contract proposal entitled "TagSense Wireless 
Identification and Data Interface" submitted to KFH by a second contractor, TagSense, Inc., on 
or about September 13, 2000 (see 'Tarts Availablity" in part vm and part VH. Schedule). 
Pursuant to this proposal, TagSense developed and delivered three elements of the B ARB Pilot 
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' System consisting of B ARB Badges, BARB Base stations, and a software SDK (System 
Development Kit) used by application programs (such as the administration subsystem 
developed by Saflink Corporation) to communicate with the base station and to access the BARB 
Badges via the base station: As stated in Exhibit G, TagSense agreed to deliver the badge and 
base station hardware, as well as the software for communicating with the badge and base 
stations, on or before November 4, 2000. The description of the badge and base station hardware 
and software functions contained in the above-noted application and discussed in connection 
with Figs, 2 and 3 of the application drawings is based upon and corresponds to the descTiption 
tbund in Exhibit C. 

10. Exhibit D. is a three page typed listing, also dated September 13, 2000, defines the 
interface specification for the API (Application Program Interfece) that was to be provided by 
the TagSense SDK. 

11 . During the paiod which began at least as early as September, 2000 when detailed, 
product specifications were provided to the two contractors, I and other members of the KPH 
team working on the BARB Project, including the seven named co-inventors named in the 
above-identified patent application, as well as the personnel assigned to this project by the 
contractors TagSense, Inc. and Saflink Corporation, were engaged in a substantial, continuous, 
diligent effort to reduce the BARB Pilot System to practice. As described in more detail in the 
following paratgra;phs 12^14, this continuous diligent effort resulted in an actual reduction to 
practice of the BARB Pilot System at least as early as May 9, 2000. 

12. It is my belief that the BARB Badge, Base Station and the software SDK were 
reduced to practice and delivered to KPH by TagSense, Inc. pursuant to the proposal, Exhibit C, 
and that these components^ as described in Exhibit C and as provided by TagSense were 
successfully operated and tested at KJH prior to the end of 2000. 

13 . It is my belief that the B ARB management subsy stem software was completed and 
delivered to KFH by Saflink, Inc. .pursuant to the AGREEMENT, Exhibit A, on or before 
February 1, 2000 and that the management subsystem software described in Exhibit B as 
provided by Saflink was successftiliy operated and tested at KFH on or before March 1, 2000. 

14. The BARB Pilot System as described in Exhibits B, C and D had been reduced to 
practice and was beingtested byMay 9, 2001. Exhibit E, a "Video Script" entitled "BARB Test 
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Announcement," describes a demonstration of the BARB Pilot system in actual operation that 
was presented to KFH hospital employees, the intended users of the system. 

15. The disclosure contained in the above-identified patent application was based on and 
is a rewritten version of the disclosure found in Exhibits B, C and D as may be readily confirmed 
by a comparison of these disclosures. The correspondence between the numbered figures of the 
application drawings and tile (frawings found in the Functional St)ecification, Exhibit B, and in 
TagSense Proposal, Exhibit C, is set forth in the list below: 



Appiication. 



Source Document 



Fig. 2 
Fig. 3 
Fig. 4 
Fig . 5 
Fig. 6 
Fig. 7 
Fig.8 
Fig. 9 
Fig. 10 
Fig, 11 
Fig. 12 
Fig. 13 
Fig. t4A 
Fig. 14B 
Fig. 15 A 
Fig. 15B 
Fig. 16 
Fig, 17 
Fig. 18 
Fig. 19 



Functional Specification Fig. I 
Functional Specification Fig. 2 
Functional Specification Fig. 3 
Functional Specification Fig. 4 
Functional Specification Fig. 5 
Functional Specification Fig. 6 
Functional Specification Fig. 7 
Functional Specification Fig. 8 
Functional Specification Fig. 24 
Functional Specification Fig. 9 
Functional Specification Fig. 14 
Functional Specification Fig. 25 
Functional Specification Fig. 18 
Functional Specification Fig. 26 
Functional Specification Fig. 20 
Functional Specification Fig. 21 
Functional Specification Fig. 22 
Functional Specification Fig. 23 



Tagsense Proposal (Badge Hardware) 
TagSense Proposal (Base Station Hardware) 
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16. T hereby declare that all statements made herein of my own knowledge are true and 
that all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under 18 U.S.C. 1001 and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 



Dated: December 1 5, 2005 Signed 




Brent A. Lowensohn 
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CONTOACTING AQREEaiEKT 



THIS AGREEMENT ±;s entered into on this day of , 2000, by and betw 

SAFLINK CORPORATION, a Delaware corporation, with its principal of f ice ' 1 oca ted at 18650 
M.E. 67 Court, Suite #210, Redmond, Washington, 98052 (hereinafter collectively rHferr«d 
to as "SAFLINK"), and KAISER FOUNDATION HOSPITALS, a California nonprofit publio benefit 
Corpor4ittoii with an of fUz^ located at 393 EA3T WALNUT STREET; 6TH FI^R PASADENA 
CAI.IFORNIA 91188 (liereinaf ter collectively referred to as *'KAISER") . 



1. DEFIMZTXOKS: 



1.1 "Statement of Work." A written documont setting forth the Contracting 
Servi ces (as defined in the Statement of Work) and Dcjliverabl us (as dtifined 
in the Stati-ment of Work) (coJ .1 actively , "Services") to be provid«d by 
SAFLINK to KAISF.R undftr.this Agreement as mutualJy agreed upon by and betwcou 
the parties, of which ia substantially specif i«d in the "Statement of Work" 
attached horeto, labeled Exhibit "A", and Incorporated hi:cein by references 

1.2 "SAFLINK Methodology.'* Consists of pra-exis ting : 
(i ) know how and methodology; 

( ii) personal and prcjr<*s?nionai progr«-jmi(i.i. ng t echni qiji:*s ; 

(iii) computer program rjlgorithms; and 

(iv) .system design, ,a r c:)n !.«cture, logic, lU.ructurc, st:qi4ence, and 
"ryanization deveJ oped or known by SAFT.INK prior to the 
commencement, of the Services. 

1.3 *'SAPL1NK Modules." Pre-i:x tincj computer program moduUi'-i proprietriiy to 
SAFT.TNK which SAFLINK m^iy umcj to provide the Oc^liverabiea . 

2. SERVICES : 



2.1 Servlecs. SAFLINK shall provide: to KAISER tht: Services which constitute- the 
Statement of Work in accordance w1 t»j the terms .ind condition:* hc^reof and the 
attached Statement of Work as referenced hereinabove. 

^..2 Change Orders. Any change in the spe.cified scope of Service.-^t rind as set 

forth in the *\Sr.citemwnt of Work" shall lu- mutually ri<jj-*-ed upon by the partie; 
in writlriij. ThR parties may utiliv.t: i.b«ir standard change Ordi^r Procedure to 
<Jcu:tjrii«nt these chan^jti.s . 

Progress Reports. SAKLINK .^hall provide KA1.5ER with cj^taiied r<:ports trom 
time to tim« regarding tJie progress ot: the Sci vices as rc:<juired UM<ii:f. the 
i;tatomi:fit of Work, any aitticSpdtr.d problems {rci5ulv«H or unr esjolved) / and an^ 
indication ot delay in f i >?f»d or tentative Si:h(:c3ules . 



MUTUAL RESPONSIBILITIES OF PARTIES : 

3. J .£>arty Contact(s), Each p.ircy sho M tJcn i qnate cern,jin f*mployeo:,- priiK:Ip>il 

points ot t:oMt,j<:t for f:omrnijni^-al ion purporit::i r imjh r.ding t^.-chrricnl and bu.«:ines.s 

iij.'iueu h<>r<MjnHe.i-. Eith«:-r patty may c:h«n<j« their rcL^puctive techiilLjl .jiid/or 

buuixK;;i;« t-.anl.nnts by written notii.t: l,o thn other. 
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Cooperation. The parties acknowledge and agree that c-erLain diLa ir>r 
or assistance ,n«y be required trom time to time in orH^, r It ' 
meet thei. obligations and exorcise S:irrighL Jereun^.r^anS^r"""'' 
request by either party to provide same, shafl Curnlsh Jo [he otJer 
aJl pertinent and/or relevant documentatj on. in the^^ lasessLn ' 
and in accordant, with Section 1, h«reinbeloi P«3 session, purauaut to 

FEES AND EXPEW3Ea ; 

4.1 Fees for Services. .Unless otherwise expressly specified i n i , ,• 

Staf.«raent of Work: ptoaaxy specitled j.n the applicable 

(J) The Services shall be provided on a -fixed-fee" basis r^r,.^ . • 

entire project and encompassing any and all services ;nd SeL;2 K? 

to be provided by SAPLIMK to kAisb^ in accirda^ce "tJ tho statff r 

Work as referenced hereinabove. ° Statement or 

Invoicing and Payn«nt. SAFLINK .shall invoice KAISER pursuant i « . ,^ • 

r:^^T^^ "rixed-rce and Payment ^chedule'/rrta^ne^L^to " 

J.occ..i,,u Exhibit rj , and incorporated herein by tererencw. 



PBRSOWNEL 
5.1 



Responsibility for SAFIINK Employees. All personnel provided bv SAFI ink ^ 
peitorm any Services under ..his Agreement .shall be considered 
umplc,y«es or agents, «nd SAFLINK shall be respoiisihl^ f -^AiLINK 

salaries (in<:luding the withho, .ij.„g or ply^'c^fLf all tTJlirir "^^^ 
p:r;,;.er''^"= co.p.n.,ation, disab. „■ ?y"bene.it^%\V;.TnH:' r^r^^^^^h • 



S foJ. ]0W3 



5.2 Inaur.no-. Contractor agre«., to maintain insurance: policies « 

• $1,000,000.00 General Indemnity 

* $1,000,000.00 Automobile I.iablli<:y 
« $ 500,000.00 Worker's CoD^ensation 

Contrwotor agrees to kooj, ..he above polidu.s in full forn« durlnc, t ^rm of 
ihis agreement, contractor agrees to provide K.ii»«r with fv Mir? t 5 
insurance as cvld.r.c^ that required courage Is I i^ .^f^ecJ. " 

rWrELLECTUAI. gKOPBRTY RIGHTS AMD OWNERSHIP; 



6.1 



and ^Ai-MNK hH.reby qrants to KAi:iKH a non-pxclua i vt- i r-^.r.^,- i i ^ J- c , 
^tixj c7icT«rvtt- J . iivii «rAv.xuaivt. JLL revo<;,ib 1 i* license to 

■ -^/.'y •^'^^"Nk pro-exist. ny works to the ext.:,,!. incorpo, ^ i int^ «r 
em>.od.ed in any r,c: I i v„,«ble, subject to mutually agroeri^retc « .> 

port,.:.s agree that either party ,„ay u.se at any Jim! nnd J^r ony IZZos. Al 

xdca«, concept., ..ti.n.. technique, that uv^v be u.4d " n.C ^.Tor 

f .r.s reduced to practice in co.u.ont.ion with the i verab eo iiX^L Lr^h 

yrants to .WLINK the non-excl u.s i rK.n- Lranster.,b.le, "rivn.'.bif '"^^^^r^C ' 
free and worldwide right to r<:pro.hK:e, display, di .s tribute,' Z^]^' "r.7."ll' 
t:r ,vative work., ba.,ed upon and otherwise markot ..nd m;.int.;,1n , h.> 
)MUverables, directly or Indirectly, to ,.„d for .SAFLINK'.^ <:n..iomers- ■ 

M "T"'^'' "'J^i*^'^-^ '^^^ '^^ directly di.,tributr":. 

Ucl v.cr,a>1.;.s l.o Hny r.„.,to,n«r primarily in the hu.i I th <:are inrlui^ttv for i 
pcMiud or i?. months .fter development o£ Che Uc: 1 i ve. r ables . Du; i , .J ftcr 
U.c tc..„ o, th.s A<uo.„,„„t. ..AKtlNK and KAI.liK wi . , <:...ute thl^ i n. t "l^nts 



S 



02-01 02:38P LOGANS MANASSAS #346 703 369 4935 p.o 



that may be appropriate or nccftssary to give full legal effVtct to this 
Section - 



CONFIDENTIALITy : 

V.l Htttual Exchange of Confidential Information. The parties anticip^it.e th^t 
each may disclose confidential information to the other. At:cordingly, the 
pi^ir ties desire to establish in this Section, terms governing the use and 
protection of certain in torm^tion one party ("Owner") may disclose, to th#» 
othcii party ("Recipient"). For purposes herco£, "Confidential Information" 
means jnCormation of an Owner: 

(1) which relates to the purpose and subject matter of. the Statement of 
Work, including computer programs, business/technical information, 
data, displays, recordings, images, and the like; or 

(ii) which, although nnt related to the Statement of Work, is ncverthcJ«5s 
disclosed hereunder, carid which, in any case, i disciost»d by ^in Owner 
or an atfijiate to Recipient in document or other tangibJo form whether 
disclosed orally or Visually and is identified as confidential; and 

(iii) Conf idoritial Information nf KAISER includes, but is not limited to: 
financial dara, personnel records, patient health information, patient 
record:,-, medical record-s, computer programs, mnrketing information and 
Hny other information relating V.n the business atf*ii rs of KAISER. 

7,2 Non -Disclosure Obligations. 



f.'A,} Kecip lent may usm Corif idential Tnformation of Owner tanly for t.he 
purpor>es of this Agreement and shalJ protect such Confidential 
Information from disclosure to others, using the same dngree of c:are 
used to protect its own proprietary information of like importance, 
but in any case using no lea.<5 than a rert^onable dtujree ot OitfA. 

1.2.2 Recipient may disclose Confidential rnformation received hereunder only 
as re.-jsonrtbly required to perform its obliyations undi?r this Agreement 
«irid only to its empJoyen.s who have a ncind to know for such purposes and 
who are bound by .signed, written agreements to protcr:n the receiv«4d 
Conf idcni:ial Information from unauthori7«d use anci disclosure* 

7.2.3 The rear.ricitions of this Agreement on use anci disclosure of 
CTonfidential Informrition .-shall not apply to information: 

(i) that is in th« possession or control of Kecipient prior to the 
time of its disclosure hHreunder; 

elicit is, or becomes publicly known, tlircjugh no wrongful act of 
Recipient; 

Lhat is leg/jlly K'.(:(>iv«d by Recipient from «-j third party free to 
disclose It without obligation to Owner; or 

that is i ndc:£)c:fidr.ir)My developed by Recipient without reference to 
Conti denti 1 I n rination . 

(V) after three (3) ycinr.s llrom the d.jt.c* execution o Jl this 

Ag r i:i:mt:nt, n«c:epl as provided in Sf.clion 7.3, hni ein below. 



(ii) 

(iii) 

(iv) 
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7,3 Rocipien1:'s Obligations. As set forth undar Section 7,2, above, the Rec)r^ien^ 
shall continue to hold, indefinitely, the Confidential Information descrih^H 
in Section 7.1 (iii), above. -"-j-ot-a 

WARRWTY, PISCIAIMER AND LIMITATIOK OF LIABILITY : 

8.1 Serviooc. SAn.TNK hereby warrants and represents thai, the Services to be 
provided herein shall be performed in a good and workroanliko mannor and 
consi.sr.enL with gencrcilly accepted industry standards, 

8.2 Afioedy. For any breach of the above warranty, at KAISRK'S soJ « discretion 
remedy shall be provided for as foJ.l.pws: ' 

(i) Require the time3y re-pertormance ot the Services as 
warranted .and contained within the Statement of Work, And in the avent 
that SAFLINK tails to re- per form the Services as stated herein, K/VISER 
shall be cnr.itled to recover all fees directly aJlocable to the 
defective Services paid to SAFI.TNK under the terras <,f this Agrecin«nt. 

8.3 Disclaimer. KXCEPT FOR THE J.J.MITED WARRANTIES SET KORTH HEKKIN, SAKLINK 
MAKES NO WARRANTIES, CONDITIONf^ OK REPRESKNTATIONS WITH RESPFCt'to THE 
SERVTCTES OR DELIVERABT.RS, WHETHER WRITTEN, ORAT., EXPRESS OU IMPLTP:D IN FACT 
OR IN LAW, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANT! KS, CONFUTIONS OR 
REPRESENTATIONS OF MERCHANTABILITY OR .fc'lTNESS FOR A PARTICULAR KJRPOSE OF 
DESIGN, MERCHANTAblLITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR 
PURPOSE, TITLF. .OK NON- INFRINGEMENT, ALL OF WUTCH ARE, TO THE EXTRNT 
PERMISSIULK HY LAW, HEREBY EXHHK.SSLY EXCLUDED AND DISCLAIMED. 

«.4 Limitation of Liability. SAFMNK^ ITS EMPLOYEES, ACRNTS, OFFICERS, 

DIRFC/]()J<S, CONTRACTORS, CONSULTANTS ANf)/OR REPR|i:SENTATIVl.;a SHALL NOT BE 
LIABLE FOR ANY .SPECIAL, INDIRRCT, INCIDENTAL, EXEMPIARY, CONSFQUENTIAL LOSSES 
OR OTHER DAMAGES, WHF.TMEK OR NOT THE POSSIBILITY OF SUCH I.cd;5SES OR DAMAGES 
HAS BEEN DI.MC:|.0.?ED IN ADVANCK OR COULD HAVE BEEN REASONABLY FORESEEN. THE 
AGCREc;aTE LIABILITY OF .SAFLINK, ITS EMPLOYEES, A«ENTS, OFFICERS, DIK^CtORS 
CONTRACTOK^', CONSULTANTS AND/OR REPRESENTATIVES, IF ANY, FOR 7VNY c:lAIM OR ' 
LOS.S ARISING OUT OF, OR CONNECTED WITH, THIS AGREEMENT, INCLUDING BREACH OF 
CONTRACT OR ANY l-;XPRESS OR IMPLIED WARRANTY OR CONDITION, NEGLIGFJMCR, USE OF 
TUK SKRVICES OR DELTVKKABLES OR IF ANY REMEDY TS DEEMED TO HAVE FAILED OF ITS 
ESSENTIAL PURPOSE, SHALL BE I.JMITED SOLELY TO KAISER, AND SHALL NOT EXCEED 
THE AMOUNTS PAID TO .^AFLINK BY KATSEK FOR SUCri .VEKVICES OR DELIVERABLES OR 
PARTS THEREOF, THAT DIRECTLY CAUSED SUCH LOSS OR DAMAGE. 

n.5 General Indemnity, Subject to the other provisions of this Agrnement, 

SAFLINK shalJ i ndnnuiily and hoid harndess Kai.s#f.r, Kaiser Permanentc Kntities 
ijnd LhHir respective otfic:t:r«, agents, and affiliates from and aga1nr*t all 
liabilities, claims, Io.s.^m.-^^ damages, demands and expenses, lnt;l uding 
reasonable .itr.o rnc^ys ' fees, arising out of or r<*.»ulting from this Agroetru.nt 
«-o the extent thnt any such iiabi J i ti o.s , claims, losses, d/iiriages, demand.'* or 
expenses .jrc: nHus^^d by any cict, nr ror or onn^sion ot SAKLINK, i lie* officers, 
<'.M»ployees, agents or eotjwultants . 

n.r> Indemnity for Alleged InTringoment . SAFMNK Warrants? thut it h.^-; Lh.j riqhL Lo 
c/rant tht: 1 i ciui.se qranted to KHi.?er under tlii.s Agreenit:nt, fre«? and ctIr^i- of 
«iny Mens r\nd encumbrance:?, ^jnci that the Surtwrjr« and Dt:l i vRrabloti will jioL 
inlrinqe upon or v/icjl.iti: wny patent, copyriijhi., trade ivi:(:r«*l . trademark, 
«cM-v.ir:e mark, or other proprietary or intcJ 1 c:<:tuai propo.rty rightri of any 
tliird party os ot tht: d,it<: surh Sottwarc: or l)c:l iverabJ t: Is deiivoted to 
Kaiser ('M nt.<:l 1 Hclual Property Ri <jhi..x" } . SAFLINK .shall indcMnn i fy , dwftinci, 
.fiave ciruJ hold harmless Kaiser, i t.s ro.spectjvc: otficfrs, emp I oy..:(us ' aruJ rnji/n\.F. 
frcjm rtll flAm-'.. actiodii, ioum::^ , dflmaqes, 1 i ri b i 1 i 1 1 es , ;1 udcjmiui t.s , «w«rd:i, 
<:o:it.s rtnd Rxpf-n.'^es , includiny ri^HSonabie attornoy:^', tecfi tjnd co.^l.;*, .jriwirwj 
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out ot claims f.h^r r.hc;-. Software iri£ringes upon or violates Intellectual 
Property Rights of others. Kaiser shall promptly notify SAFLINK Jn writina if 
Kaiser bccomas subject to any such claims. Kaiser shall, upon SAFLINK' s 
request, at SAFLINK' a expense and to the extent Kaiser's interests are not 
adverse to SAFLINK, provide reasonable assistance to SAFLINK in the defenso 
of such action. SAFLINK shaJ 1 have the sole control of the defense and 
settlement of such claims. If the Software becomes the subjoct. of a c]aim of 
infringement or violation of r,hc Intellectual Property lUqhts of a third 
party, SAFLINK may, at its soJc option and expense: 



(a) 



procure for Kaiser the right to continue using the Software? or 



(b) replace or modify the Software so that no inf ri ngciment or other 
violation of Intellectual Property Rights occurs, if Kaiser 
determines that: 



(1) 



such replaced or modified Software wil] operate In all 
material respects in conf ormi ty with the th«n-currcrit 
apeci ficAtions for the Software; and 



(2) Kaiser's use of the Software is uninterrupted and the 
per for/man ce of the Software is not impaired thereby. 
5AFLINK's obligations under i.his Agreemenr. will continue 
with respect to the replaced or modified Software as j f it 
were the original Softwar*.*. 



TERM AND OBLIGATIONS: 



9.1 TorttL. Thci i.«rra of this Agreement shaJ I crommence immcdi a ti^ly upon thn date of 
execution by tht: pcirti^.s hereinhelow, and shnll continue in effect unti .1 the 
r^tatement of Work has been fully performed unless erirlier terminated pursuant 
to Set:r.ic>n 9,2, 



9.2 Tcrminatioti . 



Kither party may tcrminritf! this Agreement, if the othor party 
breaches this Agreement (if)c:lvKUng without iJ mi i.h tion the fc.ilure to make' any 
p^ymurit w>uui du«) and the breaching party fHiJ-H to cure sut:h breach within 
thirty (30) days ot the non-br t:Hc:h tng party's writt.i:n notice to the brHaching 
pa/i.y of such breach. 



9,3 Return of Materials. Subject to Uho terms and conditions of any Statement of 
Work, or upon «:ompI«tion of any Statement of Work, either party may submit a 
written request to surrcnd«t all previously provid«-d documentation, 
including, but not limited to, memoranda, notes, records, drawings^ manuals, 
items or effects, whether tangible: or jnlangible, ot wliicrh were previously 
delivered by one paity to the other. Furthermore, this provision •^h.=*.ll apply 
to all materials made avaiJobIc: or disclosed to cither party by any third 
porty tuyiiTtzr. in connection with this Agrt:i:im:nt or any Stfitement of Work. 

y.4 Continuing Obligations. 6, 7, 0, 9,3, O.A and 10, G shall survive the 

expirat.ion or termination ot this Agreement ft^r «.ny reason. 

.10, GSWERAL; 



Notices, Except <\s otherwise provided, ail iiotice:i hc:r<:ijnder shall be in 
writinq ,jiid shall be deemed to have bet:»i Mi<:«\i vcul wh«n: 

(i) cent and received by facsimile transmission as indicated by a printed 
notice qenoraced at the time ot transmission; 
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(ii) mailed by certiCiod ,o«j.l, return receipt requcslied, post:age 

prepaid, and properly addressed to the offices of the respective 
^hh! fP^^^"^^' '^h^ introductory paragraph hereof: or at such 

addr«5 as the parties may later specify in writing for such puJool^^ 
The foregoing shal) apply regardless of whether such mail 2 IccallZ' 
or uncial m»d. accepted 

10.2 Itevger; ABcnduent. This Agrtsement ah^ll not be considered an offer K» » 
. party, «nd it shal3 not be ettcccive untii executed by b:th ^tk'^'"- 
Agr«en,ent conaui tubes and represents nhe entiru understanding of tL JJ^. 
w.th respc.t Lo the subject matter of this A^ireement anS^rg.^'afi" ^'^''^^ 
respective prior ommunicatlons, understandings, agreements, et al 
hereundt:r. This Agrc«ment may be modified ^„d/or amonded upon mutual 
agrowment and written consent by the parties herein. mutual 

10. .3 independent Contractors, The relationship of the parties is that of 

xndepcndenL contractor, and nothing herein shall be construed to create a 
i:ti«"?i^'p^:j?es:'^"'"''"' '"^•=''^^' ^ -^-^y relationship 

10.4 Severability, If any provl.,ion of this Agreement shall h« held by a court of 
competent jurisdiction to be Contrary to law or public polir^v the rem. rH^r 
provisions shaJJ remain in full force and effect ^' ""-^"i^ng 

10. b NO implied waivers The failure ot cither party to enforce at «ny tim« any 
c.r the prov.,nc,„3 hereof sh,.!! not be a waiver of .^uch provision, or any 
other pr<,vxsion, or of th^ right ot such party thereattnt to enforce anO 
provLSi-on hereof. ' ^ 

10.6 Governing I.aw. This Agreement sh.Ml be con.strued undr,r the .l«ws ot, «nd it 
required, .adjudicated in the State of c:alif ornl without regard to its 
principles or contlic:ts of law in any other Jurisdiction. 

t 

10.7 Multiple; Counterparts. This Agreemonl. may bo .:^ec.uted .'simultaneously in two 
or wnjch. shall constitute one and the same instrument. 

10.8 Assignment. This Agr>,ement shaiJ ir.ure to the benefit of, and h« bindin., 

er^^'r^nLtr^^h^M *'"v"'' " substantially of the business .nd assota-of 

eitlK.r party, whether by merger, .s^le ot aa:,«t.5, or other agrcc-ments or 
operation of Ihw. Except as provided heroin, nelt»,<,r party .shall assiyn this 
Agreement or any right or interest under this Agreement, uor delegate any 
ear^«?f t« performed und«r this Agreement, without the other 

party s prior written consent. Any attempted assignmotiL or dctooation in 
contravention of this provision shalJ bn void and Ineffective* and shall b. 
r ,"k I '"'^'""■^^^1 b^^^^h h.u.eof. Notwith.standing any other provision 

Lv ^M^MAM""Tl"' ' '^^'"'^ "w^ Agreement, to KAISRr fOUNDATION 

HEALTH PLAN, INC., ,iny of the PP.KMANENTE MP.DlCAb GROUKS or to: 

(i) uny parent sub:nci,.Hry, atti 1 i « ..«d or succc:.s.,or corporation o f KAI.SEU; 
or Lhe purch.ifl<!r o£ any ot tliH.«ie entl tl or 

(i.i) any <;orporai.ion to whii:l. kai.skr has :iol<J «!! or .suhs tantiol 1 y .^11 of 

itM' assets (inclu.lir.y i.h<, purchasor of «ny of KAISER's sub:ri «i i ,i r i <•» ) ; 



(iii) any <:orporalion or log,:*! t:nl.ily V7ith whi.rh KAISER imiy mc-.rqe or 
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contractor, KAISER is subject to various federal laws, executive orders and 
regulations regarding equal opportunity and affirmative action which alao may 
be applicable to subcontractors, SAi'LINK, therefore, agrees that any and aJl 
applicable equal opportunity and affirmative action clauses from the re<i«sral 
Acquisition Regulation irAH) at 48 cm Pa»t S2 shall be incorpo t«l.ed herein 
by reference as required, by federal laws, executive orders, and regulations 
including, but not limited to the fo3 lowing FAR clauses: ' 



(a) Equal Opportunity (Feb. 1999) at JTW 52.222-26; 



(b) Affirmative Action for Disabled Vetorana of the Vietnam Em (April 
1998) at FAR 52.222-35; 



(c) Affirmative Action tor Hoc]cer« with Disabilities (June, 199B) at FAR 
52.222-36; 



(d) Small Business Subcontracting Plan (Oct., 1999) at FAR 52- 219-9. 

If this agreement is determined to be subject to the provision/3 ef 
Section 952 of P.L. 96-499, which governs access to books and records of 
.subcontractors of services to Medicare provider.? where LhR cost of v/«lue 
of such services under tihe contract exceeds $10,000.00 over a l?.-month 
period, then SAFLINK agrees to pennit representatives of the Secretary of 
the Department of Hc^nlth and Human Services and of the Comptrcjller 
Gencr»jl to }i«ve access to the connr«cL and books, documcnt..s and recor<Js 
of SAFLINK, as necessary to vtirjfy Lhe costs of the contrrjt:t, in 
accordance with ci:iteria and procedures contained in applicable Fedatal 
regulations . 



10.10 Advertising. SAFLINK shall not, wiUioiU. the prior wril.ten consent «r KAISEr/ 
use in odvurl. i isi ruj, publicity or otherwise, tlu^ name ot KAlSfcJK FOUNDATION 
HEALTH PLAN, INC. or i tn :5uhsicJiaries , KAISER FOUNDATION HOSP lTAJjS, any ot the: 
PERMANF-NTR MRhlCA!. C.^UOUl*.?, KAISER PERMANFNTR, or the KATl^KK rERMANEMTR MIriDlCAL 
CAKK l'l<(x;HAM, or refer to the cxiatenciH of this Agri»«ment in ony pr«s5 
releases, odvortlsing nt mrJt«;?rials distributed to prospective trUMi.omers or 
oth<M third parties, except that SAFLINK may use KAISF.R' ^ name on its list of 
custo)m:r:s without obtaining, the prior wri tteii consent ot KAISER. 

IH WITNESS WHEREOF, the parties h^vo uHu.sed this Agreemisnt to be duly executed 

below. 



SAFLINK COl^PORATION 



KAiSER FOUNDATION HOSPITALS 
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EXHIBIT '*A^ 
STA!^MENT 0£* WOBK 

°eh!d^l"r Contracting Services, noliverabJ es, and delivery 

1,1 Con'tr^o'ting Services 
The contraaiug services shown below iiKludc softwirc dcvelopmem in acconLiJicc wiili die Requirements Specification ajid 
ruiicuc,n;jj Specification documents previously approved by the parties and included in (his couuract by nrfcrcnoe RcauiremcnK .nH 
capabiinics iiidicatcd as "future" in these specification documents will be considered in (lie design of Uic pilot systcnibut w H not^ 
implemented as part of this conlnict .ouiwnmoiuc 



Item ff 



6 
7' 



10 



Service 



Project Management 



Software Design 



Softw are Development (coda Si unit test) 



pa Lab ase Design & DcvcJopmnnL 
Integration Testing 



QA 



On-Sltc Tust. Support (up to 8 days) 



Documarit a t i o n Development 

Training (Materials & Trai n-tli^-Tralnerr 



Installation, Deployment, and On-Site PiJot 
Su pport (up to 6 days) 



Period of Performance 



30 Aug 0 0 - 30 Ap r 01 



4 - 



j_S_S ep 00 



11 Sep - 31 Jan 01 
11 Sep - 2<) Sep 0 0 
2 Oct - 1 Dec 00 " 



16 Oct - 31 Jan 01 



^3 Oct 



33 Jan 01 



73 Oct 



] Dec 00 



22 Nov - 31 Jan 03 



1 28 Fftb 01 
(nomina l - 30 Apr 



01) 



Additionony, travel costs for up to nighL (8) person-trips ot up to 1 wcok' 
duration each have been jncludnd in the above atoi.«ment ot work. Any additional 
person trips will rt.quir*!! contract moditicat.1 on and will bo subject to additional 



cost . 



1,2 



Delivcra blea and Delivery Schedule 



Item # 


Item 


Delivery Schedule 


1 


Troject Status Reports 


Monthly 


2 


Alpha sottwaro 


1 H Oct 2000 


3 


Bi onu-:t-.r 1 c devices (IfiT units) + MAt*server 


15 Oct ;»ooo 


4 


Bota software 


1 Nov 2000 


5 

6 


Bf.ta 2 software 


15 Nov 2000 


Final sottwarc* 


1 Doc 2000 


7 


Source code £ updated ttxecutables 


33 J^n 2001 


0 


Biometric dcvj cos (pilot units) 


31 Jan 2001 


9 


Use r * s m;i nu*i 1 ( ) 


33 Jrtn 2001 


. 10 


Trriiriiag materials 


31 Jan 2003 



*FinaJ aoft:w.irc>. is subject to correctjorw; rnquired as result ot «y«tem testing. 
Drlivfoihlr sofnv-iirc includes llic folio wiufr con fijirunirioii items (as described in the. System l'unction»il Spctiifirjition): 

~ Autliunt i <:rition Administration App 

- AuLh«nl.ication & Activation App 
Application Login Krit.fvrface 

Badge Interface DLL (including b«dge SDK wrapporu) 

- Audit flogging App 

- Kwy Management App 

Softw.uro tor t:hfi hUov**. includes all source code jud <^xecutabica , including any 
necessary coiitigur/jtion filori (rf:gir<try, i ui , elc), rocoun-i* r.i.l«5., and data 
tiles. (TliiiJ dot:« not include t)K> SAKMNK S AFservor'*^, wlri <:h is .lepiarateiy 
dullvor-iblc ijiidur SAKtiNK software license. Sec Kxhibit B, ) 
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EXHIBIT ^^B^' 
FIXED -FEE AND PAYMENT SCHEDUXA 



FEES AND PAyMEWT TERMS 

1.1 



1.2 



1.3 



Fees for th« Services arc ciharged on chct basis of a quaranl.aed fee for th^ 
entire project doscrih«d above which is $298,9bO.OO. 

invoices for fees tor thu Services :iM«ll be biilud and pay.ible in dccordanc-.. 
with the foJ .lowing wchedule: Aaancc. 



September 30/ 2000 
November 30, 2000 
March 30, 7.001 



5100,000.00 
$100,000.00 
$ 90,950.00 



Terms of payment will be nat 30 days from date of invoice, 

Non. service,:, product items that may be rnquired tor the performance of this 
contract are not included in the abov« services f «es . Thu prices for theso 
lli^ms are incJudctd in the foJJowirig schedule: for refcrnnce purpo.ses only and 



Crtn be purchased through a separate purchase order. 



Item 



Software license for SAFLINK SAFZOOO" 
SAFserviir.^" component moduJc: (price is 
j mc user enrolled i n ii AFserver databa .SH) 
Veridi com fingerprin t sensor 
Ke y Tronic tingerprint senTors 



AuthenTec finq<!£print sensors 



IriScan Securei:«m c;2 iris camera 



Total 



Quantity 



2S 





Unit Price 


Total 






$1, 248. 75 




129.00 


645.00 




119.00 


595.00 




129,00 


615.00 




ITBD) 


(TBD) 






$3, 133. 7L. 



Note: 



Quonuii.y discounts are .ivHilable tor subsequent »yst em depl ayments 
Note: Above prine.? are valid for 30 days from the: date of this AgreemctH 
Note: l5iometric devices irxtlude hardware (device I cables), drivers and 
Bxometric Service: eruvider (BSP) modules. ' 
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1 . 0 Introduction 

1 . 1 Overview 



Kaiser Permanente plans to implement an enhanced authentication capability for access to their 
Clinical Information System (CIS). This capability will involve the use of multiple technologies including 
biometrics, tokens, and PKI. The requirements for this authentication system are documented in the 
Biometric System Requirements Specification - Biometric Authentication and Roaming Badge (BARB) 
Technology Project. 



1 • 2 Scope 



This document defines the fimcttonal requirements for the enhanced CIS authentication system. 
The top down functional breakdown is graphically depicted in the form of data flow diagrams and textual 
descriptions. 

Future requirements, when included, are indicated with dashed lines, square brackets [ ], or listed 
separately as future capabilities. These future requirements do not pertain to the pilot system 
implementation, but are included so that any implications for the overall system architecture and design can 
be considered. 



The document is organized into the following sections: 

Section 2 - Functional requirements 
Section 3 - Operational sequence 
Section 4 - Data elements 
Section S - Security and availability features 
Section 6 - Future requirements 
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2.0 Functional Requirements 



The functional requirements for the enhanced CIS authentication (BARB) system are provided i; 



2 . 1 Context 



The context, or environment, that the authentication system will operate is depictc 
below. This diagram identifies all external inter&ces to the system, both human and other 
hardware/software elements. 



These inter&ces are briefly described below. 

Admtnistratpr . The BARB subsystem administrator is the person authorized and responsible for 
system configuration, security, and user management. 

User Users are Kaiser staff personnel who need to access and use the CIS system in order to 
perform their job. This includes doctors, nurses, and other staff responsible for providing patient care. 

QS. The Clinical Information System (CIS) is the mission critical application for which the 
authentication system provides secure access. 

Entom. The Entrust system provides the public key infrastructure (PKI) upon which the user's 
access credentials are based. Entrust is accessed using the EntrustSession API. 




i 



Entrust 



Figure!. Context Diagram 
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TivoH . This is an enterprise management system, which provides Application Resource 
Management (ARM) event logging and notifications. 

Figure 2 depicts Kaiser's enhanced authentication system architecture. 



Biometric/Badge 



Biometric 
Sender 



Administration 



JL 



Database 
Sen/er 
? 



Authentication & Activation 



CIS 



Login Irterface 



. Bionetiic Interface 



Entnist Session 
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Badge Interboe 



Biometric 




Biometric 


Service 




Service 


Provider 




Provider 



Bad^e 
Service 




Badge 
Service 


Provider 




Provider 



Figure 2. Kaiser Authentication Architecture. 



2 . 2 System Functional Requirements 



There are three primary functions performed by the user authentication subsystem. These are: 

• Administration 

• Authentication and Activation 

• Application Login 

Administration of the BARB subsystem is the process by which users' authentication information is 
maintained arid authentication methods are manage d, including enrollment of biometric characteristics and 
management of badge inventory. ' 

Authentication and activation is the process by which a user is initially authenticated at the beginning 
of a shift and his badge is activated. 

A pplication login verifies the identity of users and grants or denies them access to the CIS application 
at a given workstation. 

Additionally, several supporting capabilities are provided. 
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Figure 3, below, depicts the top-level functional flow for the user authentication subsystem. In these 
data flow diagrams (DFDs), the "bubbles" represent system functions, the rectangles represent external 
elements, the pair of horizontal parallel tines represents data stores, and the arrows represent data (solid) or 
control (dashed) flow. No time sequence is implied in these diagrams (Section 3 addresses process flow). 



AUTH DATABASE 





data. 



Figure 3. Top Level System Data Flow Diagram 

NOTE: Use of the label "AUTH DATABASE" refers to both biometric and badge authentication 
These functions are further described in the following paragraphs. 



1 Authentication Administration 

Authentication administration comprises one of three separate applications composing the BARB 
subsystem. It may run on a separate workstation or on the same workstation as the Authentication & 
Activation (A& A) application. Administration is the process by which users' authentication information is 
maintained and authentication methods are managed, including enrollment of biometric characteristics and 
management of badge inventory. 

This function is composed of the following subfiinctions, which are described in following 
subparagraphs. Each of these major functions should be accessible from the main/opening (tisplay page. 

• 1*1 • User management 
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2.1. I L • Badge administration Ci'^'*^ 

2 2^ \ I • Biometric administration Cf^^^) 

2 2 \ i * Access control (for the BARB subsystem administration functions) ^ ^ 

• Administrator management (for the BARB subsystem administration functions) (JfiV 



7.7. I S 



The functional flow diagram for the authentication administration function is shown below in Figure 4. 




AUTH DATABASE 



.1.1 
.1.2 
.1.3 
.1.4 
.1.5 



{ 



AucSting 



Note: All functions wHI write to ttte 
au<^ fogging functions. This is 
understood and will not te repeated 
on subsequent diagrams. 



Figure 4. Aothenticatioii Administration Data Flow Diagram 



Figure 5 depicts the general menu structure for the Authentication Administration application. 
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ADMINISTRATOR 
MANAGEMENT 



Enroll User - List Admin 

Verify Enrollmerrt j><Vp Create Admin 

Set Biometric / 1— Edit Admin 
Preference / 

J Delete Admin 

Display Biometric 
Enrollments 



Figure 5. Authentication Adminbtration Menu Structure 



2.2.1.1 



User Managemant 



User management is the process by which user accounts are created and maintained within the 
authentication system, under the control of the system administrator. The user management function is 
accessed from the main/opening page of the administration application or via top level menu. User 
information is stored in tables within the authentication database (part of the biometric/badge database). 
The subfunctions composing user management include: 

• List users 

• Create user 

• Delete user 

• Edit user 

• Import/export user (future) 

The functional flow diagram for the user management frinction is shown below in Figure 6. 
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Figure 6. User Management Data Flow Diagram 
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2.2.1.1.1 List Users 

When the "Users" tab is selected, the 'list users' function will display a list of registered system 
users, along with selected textual information associated with each user, in table format. By default, users 
will be listed in alphabetical order by user ID. By right-clicking in a different table column, the 
administrator can re-sort the user list based on the information in that column, alternating between 
ascending and descending modes. Double-clicking on a single user ED will invoke the 'Edit User" ftinction 
(see below). 

A font size of 12 points will be utilized in order to display the maximum amount of information 
that is easily readable. Vertical scrollbars will be provided to allow the administrator to view all users in 
the table; horizontal scrollbars will be provided to allow the viewing of all textual information about the 
users. Selecting another folder tab will close the 'list users' window. 



2.2.1.1.2 Create User 

This function will provide the capability to add new users to the authentication database. This 
function will be invoked via a pushbutton on the "Users" tab. Once invoked, a form will displayed into 
which the following information is to be entered: 

User ID . A unique string value consisting of a beginning alpha character followed by 6 numeric 
characters. The User ID must be consistent with the user's Entrust User ID. This is a 
mandatory entry. 

Last Name . The user's last name. Up to 35 alpha characters. This field may be left empty (null). 

First Name . The user's first name. Up to 25 alpha characters. This field may be left empty (null). 

Middle Initial . The user's middle initial. Single alpha character. If the user has no middle initial, 
this field is left blank (null). 

Title . Theuser'stitle(suchasDr., Mrs., etc.), not job position. May be left blank (null). Up to 6 
alpha characters. 

Department . The user's department name or number. Up to 30 alphanumeric characters. This 
field may be left empty (null). 

Phone Number . The usei^s office phone number. Separate fields will allow the administrator to 
enter the 3 -digit area code, 3 -digit exchange, 4-digit phone number, and up to a 5-digit 
extension. This field may be left empty (null). 

Tie Line . The user's 3 character tie line prefix (numeric). This field may be left empty (null). 

Email Address . The user's KP email address. Up to 48 text characters. This field may be left 
empty (null). 

Badge Time-to-Live . The maximum time the user's badge will be activated before expiration. 
(Default is 12 hours.) 

Additionally, firom the ^create user' window, the administrator can initiate the 'enrofl user' 
fijnction (see 2.2. 1 .3. 1 ) to enroll the biometrics of that user. 
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When all user information has been entered, the administrator may select via button 'Add User') 
to commit the new user information to the database. At this time, a validity check is made of the entered 
data to ensure that it meets data type and content specifications. The User ID is checked against the user 
database to ensure that it is unique. If all data is valid, the new user record is added to the user table of the 
authentication database and the "add user" window is closed-The user list will be updated to include the 
newly added user. 

If any data is found to be invalid, the administrator is prompted to correct the entry. At any time 
prior to selecting OK/Save, the administrator may select to cancel or abort the new user creation process If 
selected, a confirmation ("Are you sure?") will be required and if confirmed, any entered information will 
be discarded and the user information window closed. 

Note: It would be prudent to verify that the User ID is valid before committing the transaction 
[this would require EntrustSession calls as used at the Activation Station]. While not absolutely required 
for the pilot, this would be mandatory for a post-pilot deployment. [Future] 



2.2.1.1.3 Delete User 



The administrator must have the capability to delete any user from the database. To do this the 
administrator will highlight the user ID in the user list and either-select the Delete' button or press the 
•Delete' key on the keyboard. If no user ID is highlighted when the 'delete user' ftinction is selected the 
administrator will be prompted to select a user ID. When the delete function is activated, the administrator 
will be asked to confirm ("Are you sure?") prior to deleting the user fi^om the authentication database. A 
check will be made to ensure that the user identified for deletion exists within the database, in case another 
administrator almost simultaneously deleted that user fi-om another workstation. When a user is deleted all 
tables in the database associated with that user ID are deleted, including biometric tables. Once the user 
has been successfully deleted firom the database, the administrator will be notified that the delete has been 
successfijlly completed and the user list will be updated to ©cclude the newly removed user. 

Before deleting a user from the database, a check wall be made to determine if any outstanding 
badges are assigned to that user (i.e, badge assignment status = assigned). If so, the administrator will be 
prompted with a list of assigned badges and given the opportunity to revoke these badges. An entry 
regarding this action will be nuide in the audit log. 



2.2.1.1,4 Edit User 



An existing user record may be updated using the 'edit user' fimction. This fiinction will allow 
the admimstrator to change any user data except the user ID. To activate the 'edit user' function, the 
admmistrator may double-click on the user ID in the user list or may highlight the User ID and select the 
'Properties' pushbutton. Upon activation, the same form as used for 'oeate user' will be displayed, with 
all fields containing the associated user data from the database. The UserlD field will not be editable The 
administrator may use the mouse, arrow, or ub keys to move fi-om field to field and within fields to modify 
the contents of that field. From this window, the administrator may also choose to activate the 'enroll user* 
ftinction to re-enroll (and thus update) the biometric data for that user. (Once the biometric enrollment is 
complete, control will return to the 'edit user' window.) Once all desired changes have been made to the 
user record, the administrator may select via the 'Update' button to commit the updated user information to 
the database, at which time the user information window is closed. If any data is found to be invalid the 
administrator is prompted to correct the entry. At any time prior to this, the administrator may select to 
cancel or abort the 'edit user' process. If selected, a confirmation ("Are you sure?") will be required and if 
confirmed, any modified information will be discarded, no changes will be made to the database and the 
user information window closed. Once the user data has been successfully updated in the datstbase the 
administrator will be notified that the update has been successfiilly completed. 
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2.2 i 1.2 Badge Administration 

Badge administration is the process by which the inventory of badges is managed. This function 
is accessed from the main/opening page of the administration application or from a top-level menu. Badge 
information is stored in tables within the authentication database (part of the biometric/badge database). 
The subfiinctions composing badge administration include: 

• Display badge status 

• Add badge 

• Revoke badge 

• Badge turn-in 

• — Remove badge from service 

The functional flow diagram for the badge administration function is shown below in Figure 7. 



Administrator 




AUTH DATABASE 



Figure?. Badge Adminbtration Data Flow Diagram 



2.2.1.2.1 Display Badge Status 

When the "Badges" tab is selected, the list of ail badges in the inventory, along with current status 
information about that badge will be displayed in table format. By default, badges will be listed in 
alphabetical order by badge ID. By right-clicking in a different t^le column, the administrator can re-sort 
the badge list based on the information in that column, alternating between ascending and descending 
modes. 

A font size of 12 points will be utilized in order to display the maximum amount of information 
that is easily readable. Vertical scrollbars will be provided to allow the administrator to view all badges in 
the table; horizontal scrollbars will be provided to allow the viewing of ail textual information about the 
badges. Selecting another folder tab will close the 'list badges* window. 

Information to be displayed includes the following: 

Badge ID . The logical number of the badge as entered upon creation. 

Badge serial number . The manufacturer's serial number of the badge [i.e. number "burned into 

badges memory"], entered upon creation. 

Bad ge typ e. The type ofbadge technology (man-readable). 
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Badge assignment status . Current known status of the badge, either assigned, available, or out of 
service 

Badge activation status . Activated, deactivated, revoked, or inactive. 
User ID assigned . User LD of user most recently activating the badge. 
Date/time of activation . Date and time of most recent activation. 
Date/time of expiration . Date and time of expiration for most recent activation. 
Last turn-in time . Date and time that badge was most recently returned. 
Comment . An annotation that the administrator can apply to the badge. 



The most probable use for the comment field would be to indicate why the badge was removed 
from service. Examples of such an annotation could be: 

• Badge lost by "user name". 

• Badge was returned to vendor for repair. 

• Badge had hardware failure and was physically destroyed. 



2.2.1.2.2 Add Badge 

This function allows a badge to be added to the inventory of badges. This function will be 
invoked via a button on the "Badges" tab. When selected, a form will be displayed into which the 
administrator may enter the following information: 

Badge ID. The badge ID is a logical ID that will be externally assigned and physically attached to 

the badge. Initially, this will be two numeric characters. 
Badge Serial Number . This will be the manufacturer's serial number of the badge. 
Badge Typ e. The administrator will select one of the available badge technologies which will be 

identified by an assigned value (e.g. "RFID" for RF Ideas, etc.). 
Comment . An annotation that the administrator can apply to the badge. 

Once the data has been entered, the administrator may select via the "Add Badge" button to 
commit the new badge information to the database. At this time, a validity check is made of the entered 
data to ensure that it meets data type and content specifications. Then a check is made of the badge 
database to ensure that the entered Badge ID is unique. If all data is valid, the badge information is added 
to the badge table of the authentication database and the "add badge" window is closed. In addition to the 
administrator-entered information, the remaining badge inventory status fields will be initially set as 
follows: 



Badge assignment status . AVAILABLE. 
Badge activation status . INACTIVE. 

All other fields will remain unset (blank). When the "add badge'' window closes, the badge status 
list will be updated to include the newly added badge. 

If any data is found to be invalid, the administrator is prompted to correct the entry. At any time 
prior to selecting OK/Save, the administrator may select to cancel or abort the new badge creation process. 
If selected, a confirmation ("Are you sure?") will be required and if confirmed, any entered information 
will be discarded and the 'add badge' window closed. 



2.2.1.2.3 Revoke Badge 
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This function allows the administrator to "revoke" or invalidate a badge (e.g. badge reported as 
lost or stolen, employee terminated, etc.). To do this, the administrator will highlight the badge ID on the 
badge status page (see 2.2. 1 .2. 1 ) and select the 'Revoke Badge' button from the "Badges" tab. If no badge 
ID is highlighted when the revoke function is selected, the administrator will be prompted to select a badge 
ID When the 'revoke' function is activated, the administrator will be asked to confirm by manually typing 
the badge ID of the badge to be revoked prior to revoking the badge. The administrator may also make an 
entry in the comment field during the revocation process. When a badge is revoked, its activation status is 
changed to REVOKED in the authentication database, and reflected on the badge inventory status page. 

At any time prior to confirming, the administrator may select to cancel the badge revocation 
process. Once a badge has been revoked, it may not be reinstated except through the * badge turn in' 
process (see below). 



2.2.1.2.4 Badge Turn In 

At the end of the shift, users will turn-in their badges prior to leaving the facility for the day. As 
badges are turned in, the badge administrator will update the status of the badge in the badge database. 

To do this, the administrator will highlight the badge ID on the badge status page (see 2.2. 1.2. 1) 
and select the 'Turn-in Badge' button from the "Badges" tab. If no badge ED is highlighted when the turn-in 
function is selected, the administrator will be prompted to select a badge ID. When the turn-in function is 
activated, a dialog box will appear for the administrator to manually type in the badge ED for confirmation, 
then select 'OK'. Once so confirmed, the status of the badge will be changed as follows (in the 
authentication database and reflected on the badge inventory status page): 

Badge assignment status . Change to AVAILABLE. 
Badge activation status . Change to INACTIVE. 
Last turn-in time . Change to current date/time. 

The administrator will also be provided the opportunity to make an entry in the comment field 
during the badge turn-in process. 

The administrator may select 'CANCEL' to aboit the badge turn-in operation prior to confirmation. 

NOTE: This function is also used to reinstate a revoked badge or to return a badge to service that 
was previously removed. 



2.2.1.2.5 Remove Badge from Service * 

This function allows the administrator to logically remove a badge from inventory. To do this, the 
administrator will highlight the badge ID on the badge status page (see 2.2. 1 .2. 1) and select the "Remove 
Badge'' button from the "Badges'" tab. If no badge ID is highlighted when the 'remove badge fix>m service* 
fijnction is selected, the administrator will be prompted to select a badge ID. When this function is 
activated, the administrator will be asked to confirm by manually typing the badge ID number prior to 
removing the badge from service by updating the badge tables in the authentication database. The 
administrator will be provided the opportunity to update the comment field. When a badge is removed, its 
status will be changed as follows: 

Badge assignment status . Change to REMOVED FROM SERVICE. 
Badge activation status . Change to INACTIVE. 
Last tum-in time . Change to current date/time. 

Once the badge has been successfully removed, the badge inventory status list will be updated. 
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2.2.1.3 Biometric Administration 

Biometric administration is the process by which users' biometric data is enrolled into the system. 
Biometric information is stored in tables within the authentication database (part of the biometric/badge 
database). This function is accessed from a button on the user/administrator property page. The 
subiunctions composing biometric administration include: 

• Enroll user 

• Store template 

• Set biometric preference 

• Display biometric enrollments 

• Verify biometric enrollmeiit 

The functional flow diagram for the badge administration function is shown below in Figure 8. 



2.2.1.3.1 Enroll User 

Enrollment is the process by which a user's biometric information is captured and processed for 
storage and future matching. This function is activated from the 'Create Admin', 'Edit Admin', 'Create 
User' or "Edit User* functions, by highlighting the user ID on the user/admin list and selecting the 
'Properties' button, then the Enroll' button. 

Upon selection, the administrator will be provided a choice of biometrics to be enrolled, from « 
those that are available (i.e., installed on the system). The administrator may select one biometric at a time 
in which to enroll a given user. Upon selection, the application will invoke the enrollment function of the 
selected biometric technology via the HA-API interface. This will result in the return of the biometric 
identifier record (SIR), also known as a template, or a cancellation (e.g. enrollment function failed or was 
cancelled by user). 

If a valid SIR is received, it will be sent (along with the User ID) to the Store Template function 
(see below). If a cancellation is received, the screen will return to the initial biometric enrolhnent/select 
biometric window. The administrator may then enroll the user in another biometric, if desired, or exit the 
function. 




Bio 
Server 



Figure 8. Biometric Administration Data Flow Diagram 
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2.2.1.3.2 Store Template 

Upon receipt of a valid BIR and user ID from the 'enroll user* fiinrtion, the 'store template' 
function will package this information for submission to the Biometric Server. This will be accomplished 
via the client interface component of the Biometric Server, which resides on the workstation. Client/server 
communications will be via a secure RPC channel using existing OS utilities/services. 

This fiinction will then update the user record within the authentication database to indicate that 
the user has been enrolled in the particular biometric technology. This is tracked by the BUID number of 
the HA- API BSP. If no other biometrics have thus far been enrolled, the currently stored biometric will 
also be entered as the preferred biometric. 



2.2.1,3.3 Set Biometric Preference 

Once the Biometric Enrollment dialog is displayed for the current user ED or admin ID, the 
administrator can change the biometric preference by selecting a biometric method from the list box and 
hitting the "Set Preference" button. The user/admin must have already been enrolled via the selected 
method, as indicated by a checkmark. If no checkmariced method is highlighted when the 'Set Preference' 
function is selected, the administrator will be prompted to select a method. Otherwise, the selected method 
will be displayed in the preferred biometric field below the user/admin ID. 

At any time prior to selecting OK/Save, the administrator may select to cancel or abort the 
biometric enrollment process. If selected, a confirmation C^Are you sure?") will be required and if 
confirmed, any entered information will be discarded and the 'biometric enrollment' wimiow closed. 



2.2.1.3.4 Display Biometric Enrollments ^ 

This frmction will display, for a given user, the biometrics in which the user has been enrolled 
along with the preferred biometric. This function will be invoked when the administrator selects the 
'Enroll' button from the User/ Administrator properties page. From this window, the administrator will also 
be able to invoke the Enroll User (2.2. 1 J. 1) and Set Biometric Preference (2.2. 1.3 .3) functions. 

When the list of biometric enrollments is displayed, the preferred biometric will be indicated 
(either by a separate listing or via highlighting). Any enrolled biometrics for which the matching 
technology is not installed on the admin workstation will be grayed out to indicate non-availability for re- 
enrollment at that station. If other available biometric technologies are listed (to enable selection for 
enrollment), then the enrolled biometrics will be distinguished from un-enroUed biometrics by a checkmark 
or other clear indicator. 



2.2.1.3.5 Verify Biometric Enrollment 

From the Display Biometrics window, the administrator may select to verify a user biometric 
enrollment. The administrator may select any enrolled, available technology from the biometrics list and 
invoke the Verify Biometric Enrollment function by pressing the "Verify" button. 

Upon activation the selected biometric technology will be activated to perform a local biometric 
capture and processing operation, followed by a server verify operation. The results of the verify will be 
displayed (i.e.. Match or No Match). The administrator may then choose to close this window and return to 
the Display Biometrics window. 
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This function is provided in order to check the quality of a biometric enrollment to ensure the 
template is matchable by the user immediately following the enrollment process while the user is still 
available. However, the function may also be used at other times - for example, if the user has been 
experiencing trouble authenticating at the A& A station with a particular biometric technology. 

2.2.1.4 Administrator Mainagement 

Administrators are those individuals authorized to access the Authentication Administration 
application and perform the above functions. They are the system operators. Functions must be available 
to manage the list of authorized administrators and their associated data. 

This function consists of the same ftinctions as user management (described in 2.2 . 1 . 1 ) and uses 
the biometric enrollment and display biometric enrollment functions described in 2.2. 1.3. The only 
differences are that no biometric preference is associated with an administrator (they may log-in with any 
enrolled/installed biometric), no import/export function exists, and there is an additional password 
capability associated with administrators. 



2.2.1.5 BARB Access Control 

This function controls access to the BARB Administrator Application. Upon launch and 
initialization of this application, the administrator will be asked to biometrically authenticate themselves 
before the access to administrative functions are granted. 

When the BARB Administrator Application, the administrator's access will be restricted to the "Login" 
Tab and menu help functions. On the "Login" dialog, the administrator will type his/her identifier into the 
* Admin ID' field in the "Login" tab window, may enter the backup password into the password field, and 
will select the "Login" button (or depress the ENTER button). If the Admin ID doesn't match any stored 
IDs in the database, the administrator will be informed of such and the fields cleared for further attempts. 

If the Admin ID is found and no password was typed in, then the application will invoke the verification 
function of the selected biometric technology via the HA- API interface. Is the acquired biometric matches 
the stored biometric, the administrator will be informed of the match and will be granted access to the other 
areas of the dialog. 

If a password was provided, then it will be checked against the backup password currently assigned to that 
Admin ID. If they match, the administrator will be informed of the match and will be granted access to the 
other areas of the dialog. 

A logout function is provided to allow one administrator to logout so that another administrator can log in 
without closing the program. When an administrator selects the "Logout" button, the application will 
prompt "Are you sure you want to logout?". If he selects "Yes", then the "Badges", "Users", and 
"Admins" tab's will be locked down; an asterisk is added to the tab as a reminder. 

.2 Authentication and Activation 

Authentication and activation ( A& A) comprises one of three separate applications composing the 
authentication subsystem. It may run on a separate workstation or on the same workstation as the 
'authentication administration' application. Authentication is the process by which a user's identity is 
verified at the beginning of each shift, prior to badge activation. Activation is the process by which the 
user's authentication credentials are uploaded to the badge and the badge is activated for some preset 
amount of time. 
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This function is composed of the following subfiinctions, which are described in the following 
subparagraphs. 

• Validate badge 

• Check credentials 

• Biometric authentication 

• Activate badge 

• A& A utilities 

The functional flow diagram for the authentication and activation function is shown below in Figure 9. 




Figure 9. Data Flow Diagram for Authentication and Activation Application 



Note that prior to approaching the authentication and activation station, the user should have 
picked up an inactive badge from the inventory of badges. This badge must be present in order to be 
activated. 

When the authentication and activation application is initiated, a main display screen will be 
presented. Options available on this page will include: 

• Activate badge (defauk) 

• Options 

Activate badge with password change 
Deactivate badge 

Also, when the application is first initialized, it will retrieve from the Key Holder (ancillary 
function), the' crypto key for encrypting/decrypting badge data. 
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upon initialization, and thereafter, the badge technology function will (unsolicited) provide a 
badge state table to the A&A function. This table will be refreshed each time a change in state occurs 
(badge detected, badge no longer present, change in badge status). 



2.2.2.1 Validate Badge 

This function is initiated upon completion of program initialization (i.e., upon launch). The 
system will prompt the user to enter the logical badge numbw- of the badge to be activated, the user ID, and 
password, as shown below: 



Badge Activation 



9adge# 
User lb 
Password 



Figure 10. Badge Activation Window 

. The user will enter data into all fields, then press 'OK' or the "Enter/Return" key when done. The 
Tab* key will move the cursor between fields, or the mouse may be used to position the cursor, which will 
default initially to the Badge # entry box. The Badge number and User ID will be displayed as typed; 
however, the password characters will only be displayed as asterisks. 



NOTE: If at any time during the badge activation process, the process is discontinued for any 
reason, the entered password data will be purged fi-om memory. 



Upon receipt of this entry ('OK' is pressed), the A&A application will query the authentication - 
database to: 

a. Check to see if the entered logical badge ID exists. If the entmd logical badge ID does not 
exist, an error message will be displayed to the operator. 

b. Retrieve the manufacturer serial number associated with the entered logical badge ED from the 
Authentication/Badge database. 

It will then retrieve the current badge state table to see if the serial number for the entered badge 
ID is present (via the Badge Technology function). This query should return badge serial numbers for 
either one badge, multiple badges, or no badges. 

If no serial numbers are returned, the user will be prompted to position the badge for proper 
reading and the badge query will be retried. After a preset timeout period (see INI file), the user will be 
prompted to return the badge to the administrator and check out another badge and the application will 
return to the main screen (clearing all entries, and purging the entered password fi-om memory). If upon 
repositioning, a serial number is returned, then processing will continue as shown in the following 
paragraph. 
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If only one saial number is returned, then the authentication database will be queried for the status 
of that badge. The result of this query should be the data listed in Section 2.2. 1 .2. 1 . A check will be made 
that the logical badge number entered matches that from inventory. If not, or if the logical badge number 
does not exist in the inventory, the user will be asked to re-enter the logical badge number. If it now 
matches, processing will proceed. Otherwise, this will be repeated until the user has entered up to 3 logical 
serial numbers without success. At this point, the application will display an error message (asking the user 
to return this badge to the badge return area and select another) and return to and clear the main screen. 

If multiple serial numbers are returned, then the A&A application will query the authentication 
database for the status of the logical badge number entered by the user. If the serial number returned from 
the inventory database matches one of the serial numbers present, then it will be assumed that this is the 
badge to be activated and processing will proceed. If the returned serial number does not match any 
present, or if the logical badge number does not exist in the inventory, the user will be asked to reenter the 
logical badge number, which will then be queried for status from the inventory and matched against serial 
numbers present. This will be repeated until the user has entered up to 3 logical serial numba^ without 
success, at which point the user will be prompted to return the badge to the administrator and check out 
another badge. The application will return to and clear the main screen. 

The j^gnd^check (of the badge inventory status information) will be of the badge assignment 
status field. If this field reflects 'available', then processing will continue. If the badge status = "assigned" 
or "out of service", the user will be prompted to return this badge to the administrator and select another, 
and the application will return to the main screen. 

The duoicheck (of the badge inventory status information) will be of the badge activation status 
field. If this field reflects 'inactive', then processing will continue. If the badge activation status = • 
'activated' or 'deactivated', then this indicates an unretumed badge. In this case, the us^ will be prompted 
to return the badge to the administrator and check out another badge. If the badge activation status = 
'revoked*, then the user will be prompted to return the badge to the administrator and check out another 
badge. 

Next, the badge will be queried for its status (via the badge technology function). The A&A 
function will query the user's badge (with the serial number matching the logical serial number entered) for 
badge status. If enabled (check ENI file), it will check battery status to determine that the battery is 
adequately charged (i.e., exceeds minimum value in INI file). If so, processing will continue. If not, the 
user will be prompted to return the badge to the badge return area and select another, with the application 
returning to and clearing the main screen. 

If the battery check passes, then a check will be made to determine if the badge is ready for 
activation. This involves determining if the badge is located on the user's person and if the KP ID badge is 
inserted (by checking the badge state table). The INI file is first checked to determine which badge checks 
are enabled. Then the status bits are checked. The table below provides a delineation of the actions to be 
taken depending on these factors. 
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ENABLED? 


wn-person 


T 


T 


F 


F 




KP-ID 




T 


F 


T 


F 


VAUD? 


On-person 


1 


1 


0 


0 


1 


1 


0 


0 


1 


1 


0 


0 


1 


1 


0 


0 


KP-ID 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


1 


0 


ACTION 




A 


B 


C 


D 


A 


A 


c 


c 


A 


B 


A 


B 


A 


A 


A 


A 



A .= Processing continues 

B = User is prompted to insert KPID into badge, KPID checks continue until good or timeout 
C a User is prompted to attach t)adge to peison; On-person checks continue until good or timeout 
D = User is prompted to insert KPID into badge and attach t>adge to person; checks continue 
until t>oth values are good. 

Figure 11. Badge Ready Check Table 

If a check is enabled (T), but the associated value is found to be invalid (0), the user will be 
prompted to take the appropriate action to correct the condition. The faulty indicator will be continuously 
checked until the status changes to 'yes' (1) or until a preset 'badge check timeout' period (defined in the 
INT file) has expired. After the timeout expires, the user will be prompted to return the badge to the 
administrator and check out another and the application will r^m to the main screen. 

If the badge passes all validation checks (serial number matches logical badge number, badge is 
available, badge is inactive, battery is OK, badge is on-person, and ID is inserted), then control will pass to 
the Check Credentials fiinction (see below). 



2.2.2.2 Check Credentials 

Once it has been determined that a valid badge is present, then the user's credentials will be 
checked. A dialog box will be presented letting the user know his credentials are being verified ("Verifying 
Password"). Previously (see 2.2.2. 1 ), a window will have been displayed asking the user to enter their 
CIS/Entrust User ID and Password. Once *OK* or 'Enter' has been pressed, a validity check will be 
performed to determine that a) both fields contain data and that b) the entwed data is of the ccwTect format 
(as defined in Entrust API). If either field is invalid, the user will be prompted to re-enter them. If both 
fields are valid, then the following processing will be performed: 

a) The entered User ID and password will be submitted to Entrust (external interface using 
EntrustSession API) for a credential check. If the credential check is successful, then step b) 
will be performed. If the credential check is unsuccessful, then the user wall be prompted to 
reenter the User ID and Password. Three tries will be permitted. After three unsuccessful 
attempts, the user will be prompted to contact the system administrator and the application 
will return to the main screen. [Entrust may do user lockout.] 

b) The entered User ID will be checked against the Authentication database to ensure that it 
exists. If so, the user record associated with the entered User ID will be retrieved from the 
authentication database (for subsequent piocessii^) and step c) will be performed. If not, the 
user will be prompted to contact the system administrator and the application will return to the 
main screen. 

c) The authentication database will be searched to determine if any active, unexpired badges are 
already assigned to the ent^ed User ID. Ifnot, processing will continue to step d). If so, the 
user will be prompted that he aheady had another active badge and to see the system 
administrator, with the application returning to the main screen. 

d) The authentication database wilt then be searched to d^ermine if any inactive, unretumed 
badges are assigned to the entered User ID. If not, processing will continue. If so, and the 
number is less than the maximum permitted (defined in INI file), the user will be prompted 
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that he has X number of unretumed badges and to please return them to the badge return area 
as soon as possible. Processing will then continue and control will pass to the Biometric 
Authentication function (below). If so, and the number meets or exceeds the maximum 
permitted (defined in the INI file), the user will be prompted that he has exceeded his number 
of assigned badges and must see the system administrator to resolve the issue prior to any 
additional badge activations. In this case, the application will return to the main screen. 

If after a successful credential check Entrust returns a mandatory password change, see 2.2.2.5.2. 



2.2.2.3 BicnietxiG Authentication 



Once the user's credentials have been validated, biometric authentication will be performed to 
ensure that the user is who he claims to be. The biometric authentication process consists of the following 
four subfiinctions: 



• Biometric selection 

• Capture biometric 

• Process biometric 

• Verify biometric 

Figure 12, below, is the DFD for the biometric authentication function. 




2.2.2.3.1 Select Biometric 



Once the user's credentials have been validated, the user record (from 2.2.2.2.b, above) will be 
checked to determine that the user has been biometrically enrolled, which biometric technologies have been 
enrolled, and what is the preferred biometric. 

If no biometrics have been enrolled, the user will be prompted that he is not yet biometrically 
enrolled and he should see the system administrator for information regarding enrollment. The application 
will then return to the main screen. 

If one or more biometric enrollments exist, a check will be made to ensure that the preferred 
biometric is installed on the AAA station. If not, the next enrolled biometrics will be checked in sequence 
until an installed biometric technology is found or until the list is exhausted. If none of the enrolled 
biometrics is installed, a message will be displayed to the user indicating that none of his enrolled biometric 
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technologies are available and to contact the system administrator for assistance, with the application 
returning to the main screen. 

If the preferred biometric (or a subsequent enrolled biometric) is installed, then the A& A 
application will initiate a biometric capture (below), passing it the Biometric Unique ID (BUID) of the 
biometric technology to be used. 



2.2.2.3.2 Capture Biometric 

Via the Biometric Technology interface, this function will initiate a capture of the user's raw 
biometric data sample using the selected biometric technology BSP/device. This will return either a raw 
BIR or a cancellation. If a raw BIR is returned, then it will be forwarded to the Process Biometric function 
(below) for processing. If the function is cancelled, the user will be queried to choose either to a) retry 
current biometric type, b) try other biometric type [assuming the user is enrolled in the other biometric 
type], or c) abort activation, as shown in Figure 13, below. 



Cancel 


Biometric Capture 


f Retry Ills | . 




Change to Rngerprint | 
Abort Badge Activatton^ 



Figorel3. Caned Biometric Capture Window. 

If the user selects "Retry xxxxx", then the capture will be reinitiated. If the user selects "Change 
to yyyyy'*. then a capture will be initiated for the next enrolled biometric technology of the opposite type 
(e.g., if the user initially attempted an iris verification, a biometric capture of the next enrolled fingerprint 
technology that is installed will be initiated). An unlimited number of captures will be allowed. Once 
selected, the biometric capture will be reinitiated for the selected technology. If the user selects "Abort 
Badge Activation", then after a confirmation ("Are you sure?"), the application will return to the main 
screen. 

Note: The biometric capture is performed locally on the A& A station. 



2.2.2.3.3 Process Biometric 

Upon receipt of a valid raw BIR, this function will initiate processing of the user's raw BIR into a 
processed BIR, suitable for subsequent matching. This is done via the Biometric Technology interface to 
the selected BSP, which will return a processed BIR. This processed BIR will then be forwarded to the 
Verify Biometric function (below) for verification matching. 

Note: Biometric processing is performed locally on the A&A station. 



2.2.2.3.4 Verify Biometric 

Upori receipt of a BUID, processed BIR, and User ID, this function will initiate a 1 : 1 v^fication 
match via the Biometric Server function. This will be accomplished via the client interface component of 
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the Biometric Server, which resides on the workstation. Client/server communications will be via a secure 
RPC channel using existing OS utilities/services. 

The Biometric Server will return the resuhs of the verification match as either a *match' or *no- 
match*. If the results are 'match', then the user's identity has been successfully verified and processing will 
continue to the Activate Badge function (below). If the results are 'no-match', the user will be notified via a 
message box that the verification failed. He will be then given the option to "Retry xxxxx" or "Change to 
yyyyy" to try again with a diflFerent biometric, or "Abort Badge Activation^CSee Figure 13). 

If the user elects to try again, the Capture Biometric fimction will be reinitiated. If the user elects 
to try again with a different biometric type, then a capture will be initiated for the next enrolled biometric 
technology of the opposite type (e.g., if the user initially attempted an iris verification, a biometric capture 
of the next enrolled fingerprint technology will be initiated). An unlimited number of retries will be 
allowed, but each attempt will be recorded in the audit log (see 2.2.7). 

If the user elects to abort activation, the application will return to the main screen. 



2.2.2.4 Activate Badge 

This function is activated upon completion of a successful biometric authentication. At this point, 
the A& A application has data regarding the valid badge, the user, and the users credentials. The data flow 
diagram for this function is shown in Figure 14, below. 

Check 
Credentials 




Badge 

Ted? ^ 

AUTH DATABASE 



Figure 14. Activate Badge Data Flow Dugrain 

First, the badge status must be re-checked to ensure that the badge is ready for activation. This 
information is obtained by querying the Badge Technology interface for the serial number of interest. 
Upon receipt of the badge status information, the following will be checked: 

• Badge is still present. 

• Badge is 'on-person* (if check is enabled, INI file setting for specific badge technology) 

• KP picture ED is inserted (if check is enabled, INI file setting for specific badge technology) 

If the badge is not present, the user will be prompted to position the badge for writing, and the 
badge query will be retried. After a preset timeout period (see INI file), the user will be prompted to return 
the badge to the administrator and check out another badge and the application will return to the main 
screen (clearing all entries). If upon repositioning, badge presence is detected, then processmg will 
continue as shown in the following paragraph. 
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If the badge is present, the 'on-person' and KPID fields will be checked, if checicing is 
enabled for the badge technology. This is performed in the same manner as described in 2.2.2. 1 . 

Once all three conditions are met, the Upload Credentials function will be aaivated. 



2.2.2.4.1 Upload Credentials 

When the badge has been confirmed as 'ready to write,' a badge write will be issued to the Badge 
Technology interface. Three actions will be performed: 

• Reset badge 

• Initialize badge 

• Write user credentials 

First, the badge will be reset, which should bring it to some known, initial (power-up) state. This 
involves resetting the following: 

• Reset 'on-person confidence' to 100% 

• Reset 'KPID ever removed* to No/False 

• Set broadcast back-off interval (number of interval units) 

Second, the badge will be initialized. This will include setting of the global password. 

Then the following user credentials will be encrypted (using the encryption key obtained from the 
key holder, 2.2.81, during start-up) and written to the badge via the badge interface, which handles the 
security associated with the badge: 

User ID : tag = "UID", data = annnnnn, password = global PW 

User password : tag = "UPW", data = up to 16 alphanumeric characters, password = global PW 

Note - for the pilot, the global password will be hardcoded into the application and the field 
passwords will be the same as the global passwords. 

Note: User data is encrypted by the BARB subsystem before writing to the badge. 



2.2.2.4.2 Set Time-to-Live/ Activate Badge 

In addition to the user's credentials, two other writes to the badge must be performed: 

• Time-to-live 
o Activate badge 

The time-to-live value is associated with a specific user and will have previously been retrieved 
with the user record from the authentication database (see 2.2.2.2.b). This value will be written to the 
badge, via tte Badge Technology badge inter&ce as fi3llows: 

Time-to-live : tag = "TTL", data = nn (hours), password = global PW 

Note that depending on technology, this data may require conversion into an expiration date/time 
group and may be done in terms of a command rather than a data field. 

Once all pertinent data has been successfully written to the badge, the badge is 'activated' (set to 
active). Once activated, all user credentials will be purged from memory (zeroed out). 
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2.2.2.4.3 Update Badge Assignments 

Upon successful badge activation, a message will be displayed to the user showing: 

• "Activation Successful" 

• User name 

• User ID 

• Logical badge number 

• Expiration date and time 

[n addition, badge status in the authentication database i$ up<|at^ ^ foljpws: 

Badge CD . No change (not writable by this application) 

Badge serial number . No change (not writable by this application) 

Badge assignment status . ASSIGNED 

Badge activation status . ACTIVE 

User ID assigned . USER ID 

Date/time of activation . ACTIVATION DTG 

Date/time of expiration . EXPIRATION DTG 

Last tum-in time . No change (not writable by this application) 



2.2.2.5 Activate Badge with Password Ql^^^e 

The user's password may be changed in two ways: a) user initiate^ jjon-demand) password change 
or b) Entrust initiat^ (periodic) password change. The processing for these two situations is described in 
the following subparagraphs. 

In either event, the user will go through the normal badge activation sequence described in 
sections 2.2.2. 1 - 2.2.2.4, above, except as follows. Prior to activating the Upload Credentials function 
(step 2.2.2.4. 1), the Change Password function described in 2.2.2.5. 1 or 2.2.2.5.2, below, will be performed 
as a modification of step 2.2.2.2.a. 



2.2.2.5.1 Change Password 

This function provides the capability for a user initiated CIS/Entrust password change. It is 
initiated by selecting 'Options' from the main screen (see Figure 10), which brings up the following 
window: 
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Options 



mi 



Pissword Change 




Exit Appi|c«tiQh 




CIdMWi! 



!i.,!;,,jji|4. W J1|U: 



Figure 15. Opt|^l|!^^i|l0^W 

When the "Password Change' option is sele^tw} frQiJ) the main screen, the following window will 
be presented. 



Password Change 



ii ffin^.„ 



Current Password i 

: : New Passwondl ; 
Confirm Passwordi 



|-S3:: 



t Canciel J 



Figure 16. Password Change Window 



The user will be asked to enter their badge number, user ID, and password, as normally done in 
2.2.2. 1 The user will also be asked to enter the new password twice. If the new and confirm passwords 
are not identical, an error message will be displayed and the user asked to reenter the new/confirm 
passwords. 

The rules for password selection should be displayed at this time. These are: 

The new password must be at least eight characters long, but not more than 16 characters 
No particular character may make up more than half the characters in the new password 
The new password may contain no more than 2 consecutive repeating characters. 
The new password may not begin or end with a numeric. 
The new password cannot contain the name of the user's profile 
The name of the user may not make up more than half of the password 
The new password must contain at least one lowercase letter and one uppwcase letter 
The new password may not be the same as the old password 
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• The new password may not contain more than 3 consecutive identical characters in common with 
the old password. 

The user will enter data into all five fields, then press 'OK' or the "Enter/Return" key when done. 
The Tab* key will move the cursor between fields, or the mouse may be used to position the cursor, which 
will default initially to the 'Badge #* entry box. The badge number and user ID will be displayed as typed; 
however, the password characters will only be displayed as asterisks. Once 'OK' or 'Enter* has been 
pressed, a validity check will be performed to determine that a) both fields contain data and that b) the 
entered data is of the correct format (as defined in Entrust API). If any field is invalid, the user will be 
prompted to re-enter them. 

If all fields are valid, then the entered User ID, old and new passwords will be submitted to 
Entrust (external interface) for a password update. If the password change is successfiil, then control will 
pass back to step 2.2.2.2.a. The new credentials will be passed to the Upload Credentials function 
(2.2.2.4. 1), If the password change is unsuccessfijl, then the user will be prompted to reenter the 
information and the password change will be resubmitted. Three tries will be permitted. After three 
unsuccessful attempts, the user will be notified that his password has not been changed. The badge 
activation process will then continue using the old password. 



2,2.2.5.2 Entrust Initiated Password Change 

The possibility exists that at the beginning of at shift, as the user is performing the authentication 
and activation sequence, that upon success&l entry of the User ID and Password, that Entrust will notify 
that a forced password change is required. If so, the A&A application should pause its sequence of 
processing (step 2.2.2.2.a) to perform the following steps. 

A change password dialog box will be presented, prompting the user to enter the NEW password 
twice (once for confirmation), as shown below. 



Periodic Passv;ord Change 



^ 



Conflmt Panwrnd 



I OK [ f Cancel I 



Figure 17. Periodic Password Cluuige Window 

The password rules shown in 2.2.2.S.1, above, will be displayed to the user. The user will enter 
data into both fields, then press 'OK' or the "Enter/Retum" key when done. The Tab* key will move the 
cursor between fields, or the mouse may be used to position the cursor, which will de&uh initially to the 
first password entry box. Password characters will only be displayed as asterisks. Once 'OK' or "Enter* has 
been pressed, a validity check will be performed to determine that a) the new and confirm passwords 
match, b) both fields contain data, and c) the entered data is of the correct format (as defined by the Entrust 
API). If either field is invalid, the user will be prompted to re-enter them. 

If all fields are valid, then the new password will be submitted to Entrust (external interface) for a 
password update. If the password change is successful, then the process will resume at step^.2.2.2.a, with 
the new credentials replacing the old for subsequent badge upload. If the password change is unsuccessful, 
then the user will be prompted to reenter the information and the password change will be resubmitted. 
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Three tries will be permitted. After three unsuccessful attempts, the user will be notified that the password 
change has been unsuccessful and that he should contact the system administrator. The application will 
return to the main screen. 



2.2.2.5.3 [Item Intentionally Deleted] 
Section 2.2.2.5.3 was intentionally deleted. 

2.2.2.5.4 Password Change at CIS Login 

Due to shift boundaries and password timers, the possibility exists that after successfully 
activating a badge, the user's password may expire and forced to be changed sometime later in the shift, 
when attempting to log on to the CIS workstation. This situation is addressed in 2.2.3.5. 



2.2.2.6 AOl Utilities 

In addition to the badge activation functions described above, other administrative utility functions 
must also be provided as described below. These are accessible from the A&A option window (see Figure 
14) and includes: 

• Deactivate badge 

• Exit application 

2.2.2.6.1 Deactivate Badge 

For various reasons, the user may need to deactivate a previously activated badge prior to its 
programmed time-to-live. To do this, the user will initiate the 'deactivate badge* function on the A&A 
workstation. 

Once initiated, this function will prompt the user to enter the logical badge number of the badge to 
be deactivated. The application will then query the status of this badge using the Badge Technology 
interface. The application will also query the assignment status of the badge from the authentication 
database. 

Once pertinent badge data has been assembled, the application will make the following checks: 
Bad ge presence . Is the badge to be deaaivated currently present? 

Badge activation status . Is the badge status showing that the badge is currently active, with an 
unexpired time-to-Uve? 

Badge assi gnment j^atiiy Is the badge shown as currently assigned? 

If the badge is present then the serial number reported by the badge will be compared against the 
badge serial number obtained from the database. If these match, processing vnU continue. If they do not 
match, the user will be asked to reenter the logical badge number up to three times. If no match occurs by 
this time, the user will be notified and the application will return to the main screen. 

If the badge is present, active, and the serial numbers match, the title and name for the assigned 
User ID will be retrieved and a message displayed to the user as follows: 

"Hello Dr. Jones. Are you sure you want to deactivate Badge number XX?" 
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'Yes* and ?4o' options will be provided. If TMo* is selected, the application will return to the main 
screen. If Tes* is selected, the application will write to the badge as follows: 

• Badge will be reset. 

• Badge activation will be set to &lse. 

• All user data on the badge will be erased. 

Then, the badge activation status in the authentication database will be changed to 
DEACTIVATED. The user will then be notified that the badge has been deactivated and that the badge 
should be returned to the badge return area or the system administrator. 

If the badge is not present, the user will be prompted to position the badge for writing, and the 
badge query will be retried. After a preset timeout period (see INI file), the user will be prompted that the 
badge deactivation failed and to return it to the administrator. If upon repositioning, badge presence is 
detected, then deactivation will continue as described above. 

If the badge is present, but inactive, the application will notify the user that the badge is already 
deactivated. The application will then return to the main screen. 



2 .2. 2. 6.2 Exit Application 

Upon selecting "Exit Application" fi^om the A& A Options window, a dialog box will be displayed 
asking "Are you sure you want to exit?" Tes' and W options will be provided. If TVo' is selected, the 
application will return to the options menu. If Yes' is selected, the application will be gracefiilly shut 
down. 



.3 i^lication Login (Extension) 

Application login verifies the identity of users and grants or denies them access to the CIS Client 
application at a given workstation. It runs on each BARB equipped CIS workstation. Login occurs using 
the wireless token, but does not prechide manual login to the CIS Client application via entry of Usct ED 
and password. 

This fiinction is composed of the following subfiinctions, which are described in the following 
subparagraphs. 

• Maintain login state 

• Get badge info 

• Query badge status 

• Proxy credentials 

• Password update 

The functional flow diagram for the application login function is shown below in Figure 18. 
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Figure 18. Data Flow Diagram for Login Application 



2.2.3.1 Maintain Login State 

The CIS Client will notify the Login enhancement when the CIS login screen is up (displayed and 
ready to accept inputs). This function will maintain a dynamic state table, which will keep track of the state 
of the login process. Possible states are: 

• Ready for login ("ready state") 

• User currently logged on ("busy state") 

• Wait state 

The system is considered ready for login following such notification from the CIS Client. At this 
point, badge login is enabled. If a badge is recognized during this state, a badge login will be attempted. 

A user is considered to be logged on when the CIS Client notifies the login enhancement of a 
positive login result, whether that login was initiated by the login enhancement or was accomplished 
manually. This state is analogous to a "busy" state. While any user is logged on to the CIS Client, no other 
user may be logged on to the same CIS client, regardless of badge detection. This function will maintain in 
a table the currently logged on user, by User ED. 

The system is considered to be in a "wait" state under the following conditions: 

• A syntax check has been received, but no login result or logon screen up' notification has yet been 
received. 

• A negative login result has been received, but no logon screen up' notification has yet been 
received. 

• A logoff/lockup* notification has been received, but no logon screen up* notification has yet been 
received. 
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• A badge login has been sent to CIS, but results have not yet been returned. 

• A CIS shutdown notice has been received, but the login application has not yet shutdown. 

When the system is in the 'wait' state, no badge logins may be attempted. However, the login 
application must track the badges that become present during the wait state, and the order in which they 
appeared so that the first appearing badge still present may be logged on once the state changes to ready for 
login. This represents the login candidate list. 




Figure 19. $tate Transition 

This function also maintains a table as to recently logged off users (by User ID/badge number). 
Once logged off, a delay period is initiated during which time that user may not be logged back in. [This is 
to avoid inadvertent login immediately following logout, but before thie'user can leave the room.] Once the 
delay ("badge cloaking"*) time has run out, the user is removed from this **no login list** and may be logged 
in. The badge cloaking delay period is set in the INI file. 

A table is kept of recently failed badge logins. After a badge login failure (either due to syntax or 
credentials) is reported by the Proxy Credentials function, that User ID is added to the "no login list", so 
that the individual whose badge failed to properly log him in will not be precluded from manually logging 
in. The user will remain on the "no login list" until he is determined to have left the room (i.e., badge is no 
longer present). Failed manual logins will not be tracked as these are handled directly by CIS. 



The "no login" table is described in Section 4.4; 



2.2.3.2 Get Badge Izifo 



When the presence of a badge is recognized, the Badge Technology interface will send a badge 
state report to the login enhancement as an update to the badge state table. [The Application Login 
enhancement should always possess a current badge state table.] If the system is in a 'ready for login' state, 
then the first arriving badge that is a) still present and b) not on the "no login list", will become the login 
candidate. The Get Badge Info function will then query the login candidate badge for its status and login , 
credentials. In response to this query, the badge interface should return the following information: 



• Badge seri^ number 

• Badge status 

• User ID 

• Password 

• Time to live 



First, the login enhancement must decrypt the user data (user ED and password) using the 
encryption key obtained from the key holder (2.2.8.1) during startup. Then, the badge is checked to ensure 
that it is acceptable for logon purposes. To be acceptable, the badge must meet the following criteria: 

Time to live/activation indicator . UNEXPIRED (DTG is later than current time)/ACTIV ATED 
On person indicator (if enabled). ON PERSON 

Probability of removal (if enabled). > Minimum Confidence (set in INI file) 

KP ID inserted indicator f if enabledV INSERTED 

KP ID removal indicator ftf enabled). NEVER REMOVED 
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If any of the above criteria are not met, then the badge will be added to the 'no login list' until 
departing the area. The next badge on the login candidate list (if any) will then be selected and this 
function repeated for that user. 

If the above criteria are met, the badge information is then passed to the Query Badge Status 
function (below). 



2.2.3.3 Query Badge Status 

Upon receipt of candidate badge data, this function will query the authentication database to 
determine the status of this badge. If the badge is found to be valid (badge assignment status = assigned 
and badge activation = activated), then the user's credentials (User ID and Password) will be passed to the 
Proxy Credentials function (below). 

If the badge is found to be invalid, then it will be added to the 'no login list' until departing the 
area. The next badge on the login candidate list (if any) will then be selected and the 'Get Badge Info' 
fonction will be invoked. 



2.2.3.4 Proxy Credentials 

Upon validation of the badge and receipt of credentials, this function will interface to the CIS 
Client to pass these credentials in to initiate a badge login to CIS. This will follow the interface definition 
for the CIS Client login modifications. Once the login request has been made, this function will notify the 
Maintain Login State function, so that the state can be changed to Svait*. The CIS Client will respond with 
the following returns: 

• Syntax check result 

• Login result 

The syntax check should be positive since it is an automated internee, unless an error in 
transmission has occurred. If a negative syntax check is received, the badge will be added to the 'no login 
list*. [This is to avoid the "three times and you're out** feature of CIS and to allow for a nianual login^ If 
the syntax check is positive, the system continues to wait for the login resuh. 

Upon receipt of the login result, if the result is positive, then the login enhancement Maintain 
Login State function will be notified so that the state may be changed to 'busy' and the logged on User ID 
can be posted. If a negative result is received, then the Maintain Login State will also be notified, so that 
the badge can be added to the 'no login list' to allow for a manual enrollment. [This might occur if a 
password change occurred subsequent to badge activation, so the badge contains old credentials. If so, the 
'Password Update' function (below) will be invoked.] 



2.2.3.5 Password U]pdat:e 

In the event of a failed autonmtic badge login, other than for syntax reasons, a possible reason is 
that a password change occurred subsequent to badge activation. This function attempts to recover from 
this condition. 

If after an attempted automatic badge login, notification is received from CIS of a login failure 
AND an immediate (time defined in INI file) notification is received from CIS of a success&l (manual) 
login, then: . 
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If User ID for the failed badge login and the successful manual login are the same, AND the 
Password for the failed badge login and the successftil manual login are different, then it is assumed that a 
password change has occurred and the new (successful manual) password will be written to the badge. 
[NOTE: This logic is located within the CIS Client login modification.] 

To do this, the badge must be detected to be present by checking the badge state table. If the 
badge is not present, this function will not be performed. If the badge is present, then the new password 
will be uploaded to the badge as described in Section 2.2.2.4. 1 (except that only the password will be 
written - all other data will remain unchanged). 

2.2.4 Biometric Technology 

The biometric technology function represents conunercial-off-the-shelf (COTS) components 
comprising the biometric interface, module, and devices. It is accessed by the Authentication 
Administration function and the Authentication & Activation function. It is composed of the following 
subfunctions, which are described in the following subparagraphs. 

• HA-API interface 

• Fingerprint BSP 

• Iris BSP 

The functional flow diagram for the biometric technology function is shown below in Figure 20. 
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Figure 20. Biometrk Technolosr Data Flow Diagram 



2.2.4.1 HA-AFZ Interface 
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The Human Authentication API (Version 1 .03) will be used in the pilot as the standard biometric 
interface through which the biometric technology is accessed. The HA-API nintime software will be 
included as a COTS component. This interface is defined in the HA-API Specification. HA-API 
communicates directly to and manages any HA-API compliam BSPs installed in the system. 



2.2.4.2 Fingerprint BSP 

A Biometric Service Provider (BSP) module packages the biometric algorithms needed to perform 
a biometric capture, process, verify, and enrollment. For the pilot, one or more fingerprint BSPs will be 
installed on the workstation. The BSP interfaces directly with the biometric capture device (in this case, a 
fingerprint scanner) and the user to perform the requested operation. Any graphical user interface required 
to perform these operations is performed by the BSP. 



2.2.4.3 Iris BSP 



The iris BSP also performs the biometric capture, process, verify, and enrollment upon request. It 
interfaces directly to the iris scanning camera, which is the biometric capture device, and to the user. Any 
graphical user interface.required to perform these operations is performed by the BSP. 



2.2.5 Badge Technology 

The badge technology fiinction represents components comprising the wireless badge interface, 
module, and devices. The badge technology may be an existing COTS product (e.g. RF Ideas) or a new 
design not yet commercially available. It is accessed by the Authentication & Activation function and the 
Login Application function. It is composed of the following subflinctions, which are described in the 
following subparagraphs. 



• Application imer&ce 

• Enumerate badges 

• Read badges 

• Write to badges 

• Maintain badge state 

• Receive event 

• Poll badges 

• Badge #1 SDK (RF Ideas) 

• Badge #2 SDK (To be determined) 

The fimaional flow diagram for the badge technology function is shown below in Figure 21. 
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Figure 21. Badge Technology Data Flow piagrnof 



2.2.5.1 Application Interface 

I " ' 

This function provides a standard interface for the application to interface to a wireless token. 
Since two such tokens are envisioned to be supported for the pilot, the interface to the application is 
designed to be the same in both cases. The following badge flinctions are expected to be available for the' 
application: 



Function 


Information oassed in 


Information returned 


Initialize interface 


Callback data 


Badge state table (all badges) 


[Callback] 


[Receiver] 


Event data 


Enumerate badges 


Request 


Badge state table (all badges) 








Ping badge 


Badge serial number 


Success or failure 


Request badge status 


Badge serial number 


Badge status (specific badge) 


Reset badge 


Badge serial number 


Success or failure 


Initialize badge 


Badge serial number, global 
password. 


Success or failure ' 


Write badfte data 


Badfte serial number. User ID, 


Success or failure 
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password, (with tags and 
password) 




Delete badge data 


Badge serial number, tag/password 
or global password (delete all) 


Success or failure 


Read badge data 


Badge serial number, tag, 
password 


Badge data (User ID, 
password, time-to-live) 


Activate data pre-read 


Data tags 


Success or failure 


Request expiration time 


Badge serial number, global 
password 


Expiration DTG 








Activate badge 


Badge serial number, time-to-live, 
global password 


Success or failure 


Get/Set badge parameters 


Badge power (badge serial #) 
Base sensitivity 

V IMUIC llIIICUul 

Lost Bad&e timeout 


Badge power 
Base sensitivity 
visiDic iimeoul 
L.ost Badoe timeout 


Get/Set on-badge features 


Badge serial number - 

Indicator status 

Playtone 

Playwave 

Clock 

Date 


Indicator status 

Clock 

Date 









The application interface will use the callback to send the badge state table whenever a change to 
this table occurs, either due to the arrival/departure of a badge or change in status of a badge. 

NOTE: The badge time-to-iive is set at the time the badge is activated, as opposed to as an 
explicit data write operation. 



2.2.5.2 Enumerate Badges 

This function is used to determine what badges are present in the vicinity of the workstation. A 
list of badges, by badge number are returned to the application as a result of this function, in descending 
ovdef of appearance time (first appearing to last appearing). This data will be received from the badge 
SDKs in three ways depending upon badge architecture: (a) badge is polled by badge service provider for 
this information (used by RF Ideas badge), (b) badge may automatically beacon its presence, or (c) badge 
base station may provide polling functionality in firmware/hardware.. 

This function also sends badge information to the Maintain Badge Status function (see 2,2.5.2) to 
maintain a state table of all badges present and retrieves current state when needed. 

In determining continuous badge presence, a " flicker factor " is to be implemented. This is 
intended to eliminate brief periods where badge presence cannot be detected but the user is still in the 
immediate vicinity (for example, when the user moves behind an obstruction, turns away, or bends down 
out of view of the transceiver). Therefore, a default filter delay time is set (check INI file for value). If the 
period of non-detection is below this delay time, the user is still considered present and his lack of detection 
during that period is not reported to the application. If the period of non-detection exceeds the hicker time 
delay, then the user is considered to have left the vicinity and is removed from the state table. If the user 
then reappears, he is re-added to the bottom of the state table. Thus, a delay timer must be set/reset for 
each user depending on consecutive detection intervals. The default flicker factor is 3 seconds. 
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2.2.5.3 Read Badge 

When requested by the application, this function queries the badge to return data stored on-board 
the badge. Badge data is stored in the following format: 

Data tag . The identifying tag number associated with the specific data element. 

Data . The stored data element content. 

Data password . The password required to access the stored data element. 



Data to be stored on the badge includes the following: 



Data Tae 


Data Element 


DescriDtion 


Format 


UID 


CIS/Entrust User ID 


User ID of the user to which the badge 
has been assigned as a result of a 
successful activation. 


Annnnnn 


UPW 


CIS/Entrust User 
Password 


Password of the user to which the badge 
has been assigned as a result of a 
successfiil activation. 


8-16 

alphanumeric 
characters 











In order to read the data firom the badge, the following is needed: 



• Decryption key 

• Data password(s) 

All data is password protected and encrypted (prior to being written). In order to access and read 
this data, this function must provide a valid password (i.e., one which matches the stored data element 
password). The data will be decrypted by the application. Once these steps have been performed, the data 
is ready to be provided to the requesting application. 

For the pilot, a single data password will be used and will be hard-coded into the application. 



2.2.5.3.1 Data Pre-Read 

The badge interface may perform a data Pre-Read\ when activated. This allows data elements to 
be read off the badge and cached in anticipation of a request fi-om the applicatioa Upon determination that 
a new badge is present, the badge interface performs a read of the two data fields listed above. These are 
held until a request for this information is received from the application, at which time the data is 
forwarded to the application without the need to further query the badge. In addition to the cached data, the 
time cached should also be stored. The badge interface must insure that: 

e Pre-read data stored in memory is updated if any of the pre-read fields are updated.on the 
badge (i.e. data rewritten by the interface). This should only occur on a "password update 
attempt**. 

• Pre-read data is not released if the "Expiration** time is reached. 



2.2.5.4 Writ:e To Badges^ 

When requested by the application, this function writes data to the stor^e area of the badge. The 
data written is the same as that described above for the Head Badge' function. In order to perform the 
write, the badge must be present. Data will have been previously encrypted by the application. This 
function must store the data with the proper tags and passwords. 
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2.2.5.5 Maintain Badge State 

This function maintains a badge state table as to what badges are present at a given point in time 
and what their current status is. Information maintained in the state table consists of the following (for each 
badge present): 

Badge serial number : manufacturers serial number of badge 
Badge status : specific status bits (see below) 

Time first appearing : time the badge presence first detected (this session) 
Time most recently seen : most recent presence detection (this session) 

Badge status will consist of the following data: 

Reset status - 1 bit: true or &lse 
Initialized - 1 bit: true or false 
Badge on person - I bit: true or false 

Badge removal confidence - 3 bits (high value = high confidence that badge has been removed) 
Activation indicator - I bit: activated = true; not activated = false 
KPID card inserted - 1 bit: inserted = true; not inserted - false 

KPID card removed since activation - 1 bit: removed at least once = true; never removed = false 
Battery low indicator - 1 bit: low = 1 (battery charge <4); OK = 0 
BattCTy charge level - 3 bits (0 = discharged; 7 = fully charged) 
Time to live indicator - 1 bit: expired = true; not expired = 0 

Note that the table will be ordered from first appearing badge to last appearing. It will be updated 
whenever any new information becomes available. In particular, new badges appearing are added to the 
bottom of the state table, along with their time of appearance and current status; old badges detected to 
have left the area (no longer present, after flicker delay) are removed from the list; and existing badges with 
continuing presence will be updated as to most recent time seen and any changes in status bits. 

The badge state table will be passed to other fimaions or the application upon request. 



2.2.5.6 Receive Event 

For badges which broadcast their presence, this function will act as the receiver of that event. 
Events are received from the badge SDK. It will pass pertinent data along to other fimctions, which 
maintain state or interfice with the application to notify it of significant events (such as the Enumerate 
Badges function). 



2.2.5.7 Poll Badges 

For badges which do not broadcast their presence (such as the design by RF Ideas), this function 
will periodically poll the badges to determine their presence, via the badge SDK. For the pilot, since a 
small number of badges will be in use, the polling will be done by circulating through a list of badge serial 
numbers. The list of badge serial numbers will be read from the INI file during start-up. The polling will 
be continuous, with a single cycle time depending on the response time of the badge techiralogy. The 
polling interval will be set in the INI file. During the polling, as badges are determined to be present or not 
present, this information is passed back to other functions which maintain state or interface with the 
application to notify it of significant events (such as the Enumerate Badges function). 



SAFLINK Corporation 



Confidential 



26 Januarv 2001 



System Functional Specification 

Biometric Authentication and Roaming Badge Technology Project 



2.2.5.8 Badga #1 (RF Ideas) SDK 

The RF Ideas' badge SDK is a COTS product provided by the badge manufacturer as a means of 
interfacing to the particular badge technology. The badge interface must conform to the SDK API and use 
the available functions and capabilities to perform the functions described in the Badge Technology 
functions, above. 

The badge utilizes RF communication with the following features and capabilities: 

• Polling interface 

• Limited on-board memory 

• No ability to detect removal from body 

• No ability to detect insertion of KP ID badge 

This badge will be implemented for probable BARB project deployment.. Note that the pilot system 
must work with either badge #1 or #2, and that the same interface must be presented to the application, 
regardless of badge technology implemented. Badge #rs SDK also creates and makes entries into its own 
local log file. 

The Badge SDK will be implemented within an NT s^ce. 

2.2.5.9 Badge *2 SDK 

Kaiser has not yet committed to a vendor for Badge U2, It is anticipated that the badge will 
incorporate some, or all, of the following features and capabilities: 

• Broadcast presence or intelligent polling base station 

• Significant on-board memory and processing power 

• On-board encryption supporting encrypted communication with the host (encryption capability 
may be incorporated in a vendor supplied base station or may be provided in software running on 
the workstation). 

• On-board sensors and indicators (visible and/or audible) 

• On-board clock 

• Support a timeout, functionality (e.g. Time-to-Live) 

• Ability to detect presence on a body (instantaneous measurement) 

• Ability to detect removal from the user*s body 

• Ability to detect insertion of KP ID badge (instantaneous measurement) 

• Ability to determine that the KP ID badge had been removed. 

• Ability to self*<ieactivate (e.g. due to removal, due to expired Time-to-Live, etc.). 



2.2.6 Biometric Server 

The biometric server is a COTS product whose specifications are delineated in commercial 
documentation. 

Note: Information provided about the SAFSen^r is limi^^^ Any 
information provided herein regarding this server is proprietary to SAFUNK Corporation and is excluded 
from the data rights clauses of the contract. 

The biometric server application will perform the following functions: 
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• Performing additions and deletions of user records from the biometric enrollment database 

• Biometric verifications to determine if a captured biometric sample matches the previously 
enrolled sample for the claimed identity 

Figure 22 is the data flow diagram for the biometric server function. 



Auth Auth& 
Admin Activation 




Figure 22. Biometric Server Data Flow Diagram 



The biometric server interfaces to the Authentication Administration function to perform 
biometric enrollments and maintenance of the user biometric records and to the Authentication & 
Activation application to perform biometric authentications. It also inter&ces to the authmication database 
for storage and retrieval of user biometric data. It conforms to the HA-API in order to interface to the 
installed biometric technologies, which perform the actual matching operations. The HA-API and BSP . 
functions are the same as those described in section 2.2.4. 

Note that in order for a biometric verification to occur, the following must be true: 

• The user must be enrolled in the biometric technology to be verified. 

• The biometric technology used to perform the biometric capture and processing at the workstation 
must also be installed on the biometric server (less capture device). 

Biometric data stored within the authentication database by the Biometric Server will be encrypted 
prior to transmission and storage using RSA RC4 128-bit encryption. Also, communication with the client 
applications will be encrypted using RSA RC4 128-bit encryption with session keys, using Diffie-Hellman 
key exchange. 

The biometric server and authentication database are planned to execute on the same NT platform, 
which will be replicated for redundancy/failover purposes (see S.O, Security and Availability). 
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2.2.7 Auditing 

The auditing function will execute as a separate DLL on the local woiicstation hosting one or more 
of the three main applications, with local text files being generated. It will collect audit event information 
from all of the other system functions and post it to an audit log file. It is composed of the following 
subfiinctions, which are described in the following subparagraph^. 



• Create audit log 

• Receive audit record 

• Post audit record 

• Sort audit log [future] 

• Archive audit log [future] 

• Print audit log [future] 

• Clear audit log [future] 

The ftinctional flow diagram for the audit function is shown below in Figure 23. 



Auth Auth & App 

Admin Activation Login 




Administrator 



Figure 23. Audit Functioa Data Flow Diagram 



2.2.7.1 Create Audit Log 

Upon activation of the audit ftinction, a check will be made to determine if the audit log (text file) 
exists. [This file will be named BARB.log and located within the BARB director] If the file exists, then 
this function does i|othing. If the file does not exist, it is created by this function. The first «ntry into the 
audit log will be the creation event. 
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2.2.7.2 Receive Audit Recsord 

When one of the system applications creates an entry for the audit log, it is packaged and sent to 
the auditing function. The package may contain one or more audit records. Ail audit records will contain 
the following information: 

• Date/time of event 

• Event tag 

• UserlD(orN/A) 

• Workstation ID (host name) 

• Badge Serial Number (or N/A) 

• Badge status bytes 

• Posting application ID 

• Event data 



Application IDs are assigned as follows: 



Appliqi^^n 


ro 


Authentication Administration 


ADM 


Authentication & Activation 


A&A 


Application Login Enhancement 


ALE 


Badge Interface 


BIF 



Events to be audited include the following, as a minimum: 



Event tas 


Event 


Event Data 


000 


Audit log creation 










AOl 


Administrator logon to Authmication 
Administratidn application 


Admin ID 


A02 


User created 


User ID 


A03 


User deleted 


UserE) 


A04 


User edited 


User ID 


AOS 


Badge created 


Badge ID 


A06 


Badge removed from service 


Badge ID 


A07 


Badge revoked 


Badge ID 


A08 


Badge reinstated 


Badge ID 


A09 


Badge turned in 


Badge ID 


AlO 


User biometric enrollment 


User ID, BUID of enrollment 
technology 


All 


Change in biometric preference 


User ID 








BOl 


Badge activation initiated 


User ID, Badge ID 


B02 


Badge activation successful 


User ID, Badge ED, TTL 


B03 


Badge activation unsuccessful 


User ID, Badge ID 

0 1 - Failed badge presence 

02 - Badge number mismatch 

03 - Badge # does not exist 

04 - Badge already assigned 

05 - Badge invalid 

06 - Low battery 
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07 - Badge not on person 

08 - KPro not inserted 

09 - User does not exist 

10 - User already has active badge 

1 1 - Exceeded max # unretumed 

12 * Failed credential check (password 
np-match) 

13 - No biometrics enrolled 

1 4 - Biom tech not instfliled 

15 - Failed biometric auth (no-match) 

16 - Failed badge write 

1 7 - User cancelled activation 


B04 


Password change - successful 


User ID 
Change type: 

01 = User initiated 

02 - System initiated 


BOS 




User ID 
Chftn^e tvoe* 
01= User initiataed 
02 = System initiated 
Failure reason: 

01 - Old password invalid 

02 - New password unacceptable 

03 - User cancellation 


B06 


Badge deactivation by user 


User ID, Badge ID 


B07 


Biometric capture 


User ID, BUID, Biometric Type 








COl 


Badge login successful 


User ID, Badge ID 


C02 


Badge login - unsuccessful 


User ID, Badge ID 

0 1 - syntax error 

02 - CTedential error 


C03 


User logoff 


User ID, Badge ID 


C04 


Badge state table update 


New state table 


COS 


Password update 


User ID, Badge ID 

Resuhs: 

I = successful 

0 = unsuccessful 








TOl 


Biometric technology fiulure 


BUID, Error code 


T02 


Badge technology failure 


Badge type. Error code 








T03 


Biometric server failure 


Error code (if avmlable) 


T04 


Network failure 





2.2.7.3 Post Audit Record 

Audit records will be posted to a local disk file. The audit log will be 140 byte; tab delimited text 
file, suitable for import into a spreadsheet or database. All event data (other than User ID and Badge ID, 
which have their own fields) will be tagged and/or coded. 

■» 

As records are received, they are appended to the existing audit file. 
See Section 4.3 for audit file description. 
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2.2.7.4 ARM Log 

In addition to the customized audit log capability described above, the A& A application will also 
post specific (relatively high level, user related) transaction type events to the Tivoli system ARM log. All 
ARM postings will also be recorded in the Authentication Audit log. ARM events to be recorded include 
the following: 

Activate session : 

• Database query to check badge availability 

• Validate and initialize badge 

• Check entrust credentials ^ 

• Biometric Authentication - Fingerprint 

• Biometric Authentication - Iris 

• Upload and activate badge 

• Database update - badge activation/assignment status 

Deactivate session 

• Database query to check badge availability 

• Initialize badge 

• Database update - badge status 

Password Change session: 

• Entrust credential check 

• Entrust password change 

For each of the above events, start and stop transactions will be logged. A separate transaction will be 
reported for each biometric authentication attempt. 

2.2.7.5 Future Capabilities 

For the pilot, existing platform utilities will be used to handle the created and populated text audit 
file. In the future, a more sophisticated auditing capability and format is expected to be developed, to 
include security features such as access control, confidentiality, and integrity protections. In addition, 
additional functions are expected to be developed to perform the following: 

• Sort Audit Log 

• Archive Audit Log 

• Print Audit Log 

• Clear Audit Log 

Also, in the future, a central server-based audit capability is planned. 

2.2.8 Ancillary functions 

In addition to the main funaions/applications described above, there are a couple of additional 
ancillary functions that must also be implemented. These include: 

• Badge encryption key management 

• Badge parameter adjustment 
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2.2.8.1 Badge Encryption Key Management 

As described previously, all data written to the badge must be encrypted prior to writing to the 
badge (and decrypted after reading from the badge). They kpy used to perform thi^ must be generated, 
stored, and disseminated centrally, so that a badge writt^ al one worksjatipn may b^ read at another. 

A Badge Key Management utility application will be provided to perform the badge key 
management function. This application will run on the biometric server platform utilize the 
authentication database as the storage location. Upon initialization, the A&A and Login Extension 
applications will reprieve the current key from the repository. 



2.2.8.1.1 Key Generation 

The Key Manager will randomly generate 128-bit k«ys using the facilities of the CryptoAPI 
available on the Windows NT platform. RSA RC4 symmetric keys will be used. The key itself will be 
encrypted prior to storage. Protection of this key will be via (he same mechanism as used by the biometric 
server for the biometric data. 



2.2.8.1.2 Key Storage 

Keys will be stored in encrypted form within the authentication database. Password access control 
will also be in place. The key will also be written to a floppy disk for key escrow purposes. A method of 
reading m the key from the floppy to replace a corrupted or compromised key will be provided. 



2.2.8.1.3 Key Dissemination 

Keys will only be disseminated to authorized applications based on a shared secret. Keys will be 
disseminated via secure channels only. 



2.2.8.2 Badge Parameter Adjustment 

Throu^ the badge SDK API, the properties of the badge transceiver (also known as a base 
station) can be adjusted to the configuration and unique characteristics of the room/environment in which it 
IS installed. 

A capability will be provided to allow these properties to be "manually" adjusted at a given 
workstation location. Properties to be adjusted include the following (note: by definition, these settings are 
technology dependent): ® 

• 

• Base station sensitivity (RFID, possibly 2"* badge technology) 

• Badge transmit power (possibly 2"* badge technology) 

• Visibility timeout 

• Lost badge timeout 
• 

Default values for these parameters will exist in an INI file (settings will be technology 

dependent). Adjusted values will overwrite the defaults. See section 4.4 for file description. 
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Parameters which will only be stored and accessed via the INI file include the following: 

Flicker filter delay timeouts 

Badge maximum delay 

Badge polling interval (RFID only) 

Retransmission retry counter (RFID only) 

Base station receiver attenuation 



2.2.9 Database Server 

The database server provides a common interface fi*om tli^ various ^ppjications (2.2. 1 - 2.2.3) to 
the BARB database for secure access to user and badge information. The bigpietric server (2.2.6) provides 
access to the biometric portion of the database. The database server is locatecl on the same platform as the 
biometric server and shares a common database. 

Communication from the applications to the database ?^Qr wijj ep^jypted using RSA RC4 
128-bit encryption with session keys, using Diffie-Hellman key exchai^ge. S^i'p^jfjve data (i.e., 
administrator passwords) will be encrypted when stored using R^A |^C^ ^^M} ^iw^tion. 

The database server and authentication database are plap^4 jjp f^ffV|f 9^^ ^ platform, 

which will be replicated for redundancy/failover purposes (see 5.9> ^fcqnty ancj Availability). 
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3.0 Process Flows 



This section provides a high level depiction of the operational process flows within the three 
primary functional areas or applications: 

• Authentication Administration 

• Authentication and Activation 

• Application Login 

These operational sequence diagrams are not intended to convey a detailed design or use case 
scenario, but to depict the general process flow. To read the diagrams; the columns depict system 
components. Events, activities, or processes are shown within rectangular boxes. Decisions are shown as 
diamonds. Data or control flows are shown as arrows. The sequence in time is read downwards from top 
to bottom. 

Note that the processes described to not typically include exception processing. 
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3.1 Authentication Administration Process 



This section describes the sequrace of operational process flows that occur within the 
Authentication Administration application. Figure 24 shows the process flow. 
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Figure 24. Authentkation Administnitioii Process 
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3.2 Authentication and Activation Process 



This section describes the sequence of operational process flows that occur within the 
Authentication and Activation application. Figure 25 shows the operational sequence diagram for the 
Authentication and Activation application. 
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Figure 25. Authentication & Activation Process 
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3.3 implication Login Process 



This section describes the sequence of operational process flows that occur within the Application 
Login function. Figure 26 shows the operational sequence diagram for this function. 



Apptication Login 
User AppWS 



CIS 



Badge 
Interface 



Badge 
Technology 



Database 



Approaches WS 



Psffofin CIS 



Prvsstoytor 
to dni p & transfer 



Create badge 
state table 



Set looin state ready ^i- 



Decrypt data 
Check: 

•"no login' list 

• Badge ttatus in OB 



• Set callbacks 
-Enum badges 



Key Mgr; send key 



Badge Ostatiia 



U>gin screen up 



iR or RP signal , 



Uaarcmthnbah 



rteaa paoge ossa 
(provide tag &PW) 



NolHy interface 



Dtdff$ atBtus dato 



Gend encrypted 



Sofxl cfBdentiBli to CIS 



Check rosulta 
Update login stale 
3 mxgss - Busy 
Failed - Watt 



Accept & validate 
credentials 
•Syntax check 
•Login result 



Continue to: 
•Collect tndge irto 
• Notify app of chgs 



aetata 


itotoV«ar 


Add us 


lerto-nologin-IM: 



• Riooelve oommend 
•Lockup system 
•Notify of lockup 



• Set login itatB ready 

* Ctisck badge utalus 



Login screen up 



Figure 26. Application Login Process 
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4.0 Data Elements 



This section defines the stored data elements for the enhanced CIS authentication system. 

4.1 Authentication Database 



4.1.1 User Data 

User data is contained in the following tables: 
USER MAIN 



Field Name 


Field Sbse 


Field Type 


Description 


User ID 


7B 


String 


A unique string value consisting of a 
beginning alpha character followed by 6 
numeric characters. 


Last Name. 


35 8 


String 


User's family name. 


First Name 


25 B 


String 


User's given name. 


Middle Initial 


IB 


Char 


User's middle initial. Blank if none. 


Title 


6B 


String 


User's title (Dr., Mr., Mrs., etc.). Not job 
position. 


Department 


30 B 


String 


Name or number of user's assigned 
department. 


Phone Number 


15 B 


String 


User's office phone number (numeric). 
Includes 3 digit area code, 7 digit phone 
number, and optional extension (up to 5 
digits). 


Tie Line 


3B 


String 


User's tie line prefix. 


Email Address 


48 B 


String 


User's KP email address. 


Defauh Badge 
Time-to-live . 


4B 


Integer 


Number of hours for which the user's badge 
will be activated, before expiration. De&uh 
= 12 hours. 


USER BIOMETRIC PREFERRENCE * 


F^ldN4^^f 


Rf^ Spw 




Df^ripfion 










User ID 


7B 


String 


A unique string value consisting of a « 
beginning alpha character followed by 6 
numeric characters. 
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Biometnc 
Preference 


128-bit 


Binary/Hex 


BUID of preferred biometric technology. 


Account 
password 


16B 


Binary 


Not used. 



BUID = Biometric Unique Identifier (HA-API definition) 



* Tables indicated with an astoisk are standard SAFserver tables, which will be utilized 
unmodified. 



4.1.2 Administrator Data 



ADMINISTRATOR MAIN 



F^fhtNgmc 




Fi^k^TYpc 












User ID 


7B 


String 


A unique string value consisting of a 
beginning alpha characto' followed by 6 
numeric characters. 


Last Name 


35 B 


String 


User's family name. 


First Name 


25 B 


Strini^ 


User's given name. 


Middle Initial 


IB 


Char 


User's middle initial. Blank if none. 


Title 


6B 


String 


User's title. 


Department 


30 B 


String 


Name or number of user's assigned 
department. 


Phone Number 


15 B 


String 


User's office phone number (numeric) 


Tie Line 


3B 


String 


User's tie line prefix. 


Email Address 


48 8 


String 


User's KP emml address. 


Password 


16 B 


Binary 
(encrypted) 


Administrator's backup password for access 
to the Auth Admin application. 



4.1.3 Badge Data 



BADGE INVENTORY 



Fiel^ 


Field Size 




D^nption 


Badge Serial 
Number 


4B 


Ulong 


A unique number assigned by the badge 
manufacturer (in badge ROM and visually 
readable on badge surface). 


Badge Logical 
ID 


IB 


Integer 


Badge number assigned by administrator.. 
[May also be affixed to badge. 


Badge Type 


4B 


String 


Type (rfbadge technology (RFID or HPIR). 










BADGE INVENTORY STATUS 


Field Name 


Field Size 


Field Tvne 


DcscriDtion 


Badge Serial 
Number 


4B 


Uloi% 


The nuumfacturer's serial number of the 
badge. 
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Badge 

Assignment 

Status 


1 B 


Char 


1 = "assigned" 

2 = "available" 

3 = "out of service" 


Badge Activation 
Status 


IB 


Char 


1 = "activated" 

2 "deactivated" 

3 = "revoked" 

4 = "inactive" 


User ID 
Assigned 


7B 


String 


A unique string value consisting of a 
beginning alpha character followed by 6 
numeric characters. 


Date/time of 
activation. 


SB 


Datetime 


Date and time of most recent activation 
(GMT). 


Date/time of 
expiration 


8B 


Datetime 


Date and time of expiration for most recent 
activation (GMT). 


Last turn-in time 


SB 


Datetime 


Date and time that badge was most recently 
returned. (GMT) 


Comment 


79B 


String 


Badge annotation, particularly why a badge 
was removed from service. 



Notes - 

(1) Datetime format displays as: dd/mm/yyyy hh:mm:ss XM. 

(2) Time displayed at workstations as local time. 

(3) Time stored within and displayed at server (via DBMS viewer) as GMT. 



• 1.4 Bionatric Data 



BIOMETRIC DATA (mukiple) * 



Field Name 


Field Size 


FieI4tYpe 


DescriDtion 


User ID 


7B 


String 


A unique string value consisting of a 
beginning alpha character followed by 6 
numeric characters. 


Biometric 
Technology ID 


4B 


Intego* 


BUID of creating BSP 


BIR 


Variable 


Binary 


Biometric Identifier Record containing the 
enrolled biometric template(s) created by 
the enrolling BSP. 


RawBIR 


Variable 


Binary 


Not used. 



BIOMETRIC TYPE CROSS-REFERENCE (multiple) 







FifhITYPf 


DcKTiptiqii 










Biometric 
Technology ID 


4B 


Integer 


BUID of BSP 


Biometric Type 


2B 


Mask 


Type of biometric technology (i.e., 
fmgerprint, face, voice, iris ...) 
(Use as defined in BioAPIl 
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4.1.5 Authentication Database Schema 



BADGE INVENTORY 
Badge ID 

Badge Serial Number 
Badge Type 



BADGE INVENTORY 
STATUS 

Badge Serial Number 
Assignment Status 
Activation Status 
User ID Assigned 
Dateftime Last Activation 
Most Recerrt Expiration Time 
Date/time Last Tunvln 
Comment 



USER MAIN 

User 10 
Last Name 
First Name 
Middle Initial 
Title 

Department 
Phone Number 
Tie Line 
Email Address 
Default Time-to-Live 



USER BIOMETRIC 
PREFERENCE 

User ID 

Bio. Preference (BUID) 



t.n 



BIOMETRIC DATA 

User ID 

BSP to (BUlO) 

BtR 



BIOMETRIC TYPE 

BSP ID (BUID) 
Bk). Tech. Type 



Figure 27. Authentication Databasje Schema 



4.2 On-Badge Data 



ADMINISTRATOR 
MAIN 

User ID 
Last Name 
First Name 
Middle Initial 
Title 

Department 
Phone Numt)er 
Tie Line 
Email Address 
Password 



Data stored on the badge is as follows: 



TAG 



DATA 



PASSWORD 



Data Ta^ 

(ulong) 


Data Element 


Description 


Format 


UID 


CIS/Entrust User ID 


User ID of the user to which the badge 
has been assigned as a result of a 
successfiil activation. 


annnnnn 


UPW 


CIS/Entrust User 
Password 


Password of the user to which the badge 
has been assigned as a resuh of a 

successful activation. 


8-16 

alphanumeric 

characters 


TTL 


Time-to- 

Live/Expiration 

date/time 


Time at which the badge will become 
expired/inactive. 


DTG 



Note: TTL is not stored as user data in Badge #2, but is set as an expiration timer. 
For the RFIDeas badge, the 2 16-bit registers will be populated as follows: 
Register 1: 
Register 2: 
Where: 



UUUUUUU SSSSDDDD 
0123456701234567 
PPPPPPPPPPPPPPPP 



UUUUUUU 


User ID 


ssss 


Status Bytes 
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DDDD 


Time to Live (date/time) 


PPPPPPPPPPPPPPPP 


Password 



4.3 Audit Log 



Field Name 


Field Size 


Field Tvoe 


Descrintion 










Event Tag 


3B 


String 


Tafi identifvinc tvoe of event ( «;ee Sec 
2.2.7.2 for tag assignments) 


Date/time of 
Event 


14 B 


String 


Date and time the event occurred 
(YYYYMMDDHHMMSS) 


User ID 


7B 


String 


A unique string value consisting of a 
beginning alpha character followed by 6 
numeric characters. 


Workstation ID 


32 B 


String 


Host name of workstation where event 
occurred 


Badge Serial 
Number 


10 B 


String 


A unique number assigned by the badge 
manufacturer (in badge ROM and visually 
readable on badge surface). 


Badge Status 


10 B 


Binary 


Specific badge status bits (each field 
converted into bytes). 


Posting 

Application ID 


3B 


String 


Assigned identifier of application detecting 
event and posting record to audit log. 


Event Data 


51 B 


String 


Data specific to event (field tagged) or text 
explanation. 



The printed audit log format will appear as follows: 
IS3MSli7A')Q12345ti7A1QlS3HSIi7ai0123H5(i7ai01SaH5b7A1015aMSli7fl<)aiS3M5li7A')0 

EEEAYYynnnDDDAHHHnnSSAUUUUUUUAUUUUUUUUyUldUUUUUUUUUyUUUUUUUUUUyABBBBBBB 
BBBaSSSSSSSSSSaAAAaTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 



4 . 4 other Data Stores 



BADGE STATE TABLE (multiple) 



Field Name 


Field Size 


Field Tvoe 




Badge Serial 
Number 


4B 


Ulong 


A unique number assigned by the badge 
manufacturer (in badge ROM and visually 
readable on badge surface). 


Badge Status 


2B 


Binary 


Specific status bits (see definition below). 


Time First 
AppearinK 


SB 


Datetime 


Date and time the badge presence was first 
detection (this session) 


Time Most 
Recentlv Seen 


8B 


Datetime 


Date and time of most recent presence 
detection (this session). 
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BADGE STATUS BITS 



Fietd 
Number 


Number 
of Bits 


Field Name 


DescriDtion 


I 


1 


Reset status 


True/false 


2 


1 


Initialization 
Indicator 


True/False 


3 


1 


On-person 
(instantaneous) 


1 = Currently on person 
0 = Currently not on person 


4 


3 


Removal probability 
(determined over 
time) 


High value = high probability that badge has 
been removed from person at some time since 
reset. (7=definitely removed, 0=defmitely not 
removed) 


5 


I 


Activation indicator 


I = activated 
0 = not activated 


6 


1 


KPID inserted 
(instantaneous) 


I = inserted 
0 = not inserted 


7 


1 


KPID removed 
(det^mined over 
time) 


1 = removed at least once 
0 = never removed 


8 


1 


Battery low indicator 


1 = low battery (Field 9 < 4) 
0 = battery OK 


9 


3 


Battery charge level 


High value = fully charged 
0 = discharged 


10 


I 


Time to live indicator 


1 = TTL expired 
0 = TTL not expired 



KEY REPOSITORY 



Field Name 


Field Si^ 


Field TvDC 




Encryption Key 


16 B 


Ulong 


A unique number assigned by the badge 
manufacturer (in badge ROM and visually 
readable on badj^e surface). 


This value is encrypted within the database. 
INI FILE 


Field Name 


Fi^fWSiz^ 


Fi^ldTYpe 


Description 


Badge 

repositioning' 
timeout 


IB 


Integer 


Length of time that the system will wait 
when attempting to detect the presence of a 
badge before timing out (de&uh = 60 sec) 


Enable battery 
check 


IB 


Boolean 


True (1) indicates that a battery check is to 
be performed; False (0) indicates that no 
check is to be attempted (de^lt =1). 


Minimum battery 
charge level 


IB 


Integer 


Value between 0-7 indicating the minimum 
value for which the battery is considered to 
be adequately charged for activation 
(default = 3). 


Enable on*person 
check 


IB 


Boolean 


True (I) indicates that the on-person check 
is to be performed; False (0) indicates that 
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no check is to be performed (de&ult - I). 


Enable on-person 
confidence chedc 


1 B 


Boolean 


True (1) indicates that the on-person 
confidence check is to be performed; False 
(0) indicates that no check is to be 
performed (defauh ~ I). 


Maximum on- 
. person/removal 
confidence 


1 B 


Int^er 


Value between 0-7 indicating the minimum 
acceptable confidence that the badge has 
not been removed since activation (default 

=3). 


Enable KP badge 
inserted check 


AB 


Boolean 


True (1) indicates that the KP badge 
inserted check is to be performed; False (0) 
indicates that no check is to be performed 
(default = 1). 


Enable KP badge 
removed check 


IB 


Boolean 


True (1) indicates that the KP badge 
removed check is to be performed; False (0) 
indicates that no check is to be performed 
(default =1). 


Nfaximum 
unretumed 
badges 


IB 


Integer 


Maximum number of unretumed badges 
allowed for a user ID before no further new 
badge activations are allowed (de&uh = 3). 


Badge cloaking 
time 


IB 


Integer 


Number of seconds that a present badge will 
be ignored for automatic CIS lo^n purposes 
(defauh = 20). 


Default time to 
live 


4B 


Integer 


Defauh value of badge time-to-live for a 
given user (hours). Default = 12 hours. 


Maximum time 
to live 


4B 


Integer 


Maximum allowable badge time-to-live 
(hours). De&uh = 48 hours. 


Biometric server 
address (primary) 


25 B 


String 


The host name of the primary biometric 
server. 


Biometric server 

address 

(secondary) 


25 B 


String 


The host name of the backup biometric 
server. 


Biometric 
database name 


25 B 


String 


Name of authentication database. 


Failover timeout 


I B 


Integer 


Timeout period after making a request to 
the primary server and re-initiating that 
request to the secondary server. In 
milliseconds (defauh = 1000). 


Password update 
timeout 


IB 


Integ^ 


Length of time between failed auto login 
and successful manual login, within which a 
password update attempt will be performed 
(in seconds). Default - 20 seconds. 


Enable auto 
logoff 


IB 


Boolean 


True (1) = enabled 
False (0) = disabled 
De&ult = 0. 


Entrust ini 
filename 


12 B 


String 


Name of file to be used to s^p entrust 
inter&ce. 



ENVIRONMENTAL INI FILE (may be combined with above) 



Field Nune 






Dcscrintion 










Flicker fiher 
period 


IB 


bitter 


Time period (in milliseconds) within which 
a loss of badge detection is considered an 
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anomaly and is not reported as a badge 
departure. Etefault - 3000 ms. 


Base Station 
Sensitivity 


1 B 


Integer 


HP badge only. Sensitivity setting for IR 
receiver. 


Base Station 

Receiver 

Attenuation 


1 B 


Int^er 


RFIDonly. Setting for base station RF 
receiver attenuation. 


badge Power 
Setting 


1 B 


Integer 


HP badge only. Transmitter power output 

setting. 


Retransmission 
Retry Counter 


1 B 


Integer 


RFID only. Maximum number of retries 
when transmission errors are detected. 


visiDie iimeout 


IB 


Integer 




Lost Badge 
Timeout 


IB 


Integer 




BADGE INI FILI 






Field Name 


Field Size 


Field Tvoe 


DescriDtion 


Badge serial 
number* I 


4B 


Ulong 


Serial numbo- of RFlDeas badge in 
inventory (for polling list). 


Badge serial 
number #2 


4B 


Ulong 


Serial number of Rl^lDeas badge in 
inventory (for polling list). 










Badge serial 
number #N 


4B 


Ulong 


Senal number of RFIDeas badge in 
inventory ffor polling list). 


Badge polling 
interval 






Time between successive polls (ms), 
(default = 100). 



LOGIN STATE TABLE 



Field Name 


Field Spf 




DescriDtion 


Login state 


1 B 


Im^er 


1 = Ready 

2 = Busy 

3 = Wait 


Current login ID 


7B 


String 


User ID ofcumently logged in user. Blank 
if no user logged in. 


Current login 
badge 


4B 


Ulong 


Serial number of badge currently logged in.~ 
Blank if no user logged in. 



LOGIN CANDroATE LIST (muitipie) (may be combined with above) 



Field Name 


Field Size 


FieWTYiK 


DescriDtion 


User ID 


7B 


String 


A unique string value consisting of a 
beginnipg alpha character followed bv 6 
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numeric characters. 


Badge number 


4B 


Ulong 


A unique number assigned by the badge 
manufacturer 


Cloaking 
indicator 


1 B 


Boolean 


0 = not cloaked 

1 = cloaked 


Cloak start time 


4B 


Long 


Time when cloaking began. 


Notification 
indicator 


I B 


Boolean 


Indicates whether the application has been 
notified of this user. 

0 = not notified 

1 = notified 


No-iogin 
indicator 


1 B 


Boolean 


Indicates if badge is on no-login list. 

0 = not on list 

1 = on list 



NO-LOGIN LIST (may be combined with above) 



Field Name 


Field Siz^ 




Dfs^riptiop 










User ID 


7B 


String 


A unique string value consisting of a 
beginning alpha character followed by 6 
numeric characters. 


Badge number 


4B 


Ulong 


A unique number assigned by the badge 
manufacturer 


No-login reason 


IB 


Char 


1 = User logoff (cloak time applies) 

2 = Failed auto login (reset wten departure 
deteaed) 

3 = Bad badge status (reset upon departure) 

4 = Badge revoked (reset upon departure) 

5 = Bad syntax check (reset upon departure) 
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5.0 Security and Avail^^^^ty 



This section describes the security and availability requirements for the system. 

5.1 Security Features 

■ . ' ■ n ■' ' 

Security features fall into 2 primary categories, which are describe^ in the following sections. 

• Access control 

• Encryption 

5«1.1 Access Control 

Access controls prevent access by unauthorized personnel or so^are entities. Access controls 
will be provided for the following: 

Authentication administration application . Only BARB subsystem administrators may access 
this application to protect against unauthorized personnel performing user and badge 
management functions. BARB subsystem administralors will be biometrically authenticated 
to access this application. A backup password access mechanism will also be supplied. 

Authentication database access . Access to the biometric/badge database will be password 
protected. 

Badge data access . Access to data uploaded to a badge will be password protected. 
Passwords include a global password and individual data field passwords. For the pilot 
system, a single password will be utilized and will be hardcodol within the readin^writing 
application. 

All password data must be purged when its immediate use has been completed. 

The BARB subsystem provides a user authentication facility for CIS as described in Section 2. 
The BARB subsystem does not provide CIS with any authorization capabilities (access controls are 
detenmined by CIS). 



5.1.2 Encryption 

Encryption of sensitive data is required for confidentiality and integrity purposes. The following 
data will be encrypted: 



All biometric data transmitted between platforms (i.e., client/server communications) will be 
encrypted. The Windows Crypto API will be used wherever possible. Client/server 
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communications will be encrypted using RSA RC4 128-bit encryption with session keys, 
using Diffie-Hellman key exchange. Secure RPC also provides mutual authentication of 
sender/receiver. 

Biometric data stored within the authentication database by the Biometric Server will be 
encrypted prior to transmission and storage using symmetric RSA RC4 128-bit encryption. 
All symmetric keys will be randomly generated and securely stored (encrypted). Multiple 
levels of protection is preferred. 

Data transmission to/from the badge will be encrypted if supported by the underlying badge 
technology. 

All application data will be encrypted by the BARB subsystem before being sent to the 
badge.. Encryption keys will be randomly generated and securely stored (encrypted) on the 
central server. These keys will be distributed only to authorized applications (shared secret). 
Secure transmission will be used (secure RPC). 

Strong encryption (128 bit keys) will be used. Secret and private keys will be protected from 
compromise. Any distribution ofkeys will use secure mechanisms. Key escrow (for the biometric 
database) will be provided. 

A mechanism of synchronizing keys between the redundant biometric/database servers will be 
provided. Once the encryption key has been generated on the primary server, a utility will be provided to 
move that key to the secondary server(s). This mechanism involves writii^ the key to a floppy disk at the 
primary server and reading it at the secondary server. Once created, the floppy disk containing the 
encryption key will serve to provide a key escrow mechanism for use in restoring the BARB system should 
a major failure occur (e.g. concurrent registry corruption on both biometric servers, etc.). The floppy disk 
will be given to Kaiser administrative personnel who will be responsible for storing the encryption key 
escrow disk in a secure location. 

r 

[Future - periodic key changes will be accommodated.] 

5.2 System Availability Features 



The biometric server and database must be implemented redundantly with automatic failover 
capability to avoid this being a single point of &ilure. For the pilot, this will be accomplished using dual 
SAFservers and SQL Server rq)lication, with client initiated retries, as shown in Figure 28, below. 



NT Server - Primary NT Server - Secondary 





SQL Server 
Replication 




SAFServer 


SAFServer 


1 


1 


SQL Server 


SQL Server 
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Figure 28. Server Replication Configuration 
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Two SAFServers are set-up using SQLServer replication. In this case, one server is the primary 
(or publisher) of the information and the other is the secondary (or receiver) of the information. In this 
case, at pre-defined intervals, the biometric database is automatically "replicated" from the primary to the 
secondary database (initially, the entire database is replicated, then only changes between intervals). 

In this case, the client is aware that two (or more) SAFServers exist. If, after a pre-defined 
timeout, the primary server fails to respond to a request, then the client assumes that a failure has occurred 
and sends the same request to the secondary server. 

Replication is a standard part of SQL Server. It does require a fair amount of expertise to 
configure property. Note also that since the SAFServer encrypts the biometric data prior to storing it 
within the SQL database, part of the configuration involves sharing of the encryption keys between the 
primary and secondary servers. 

[Future - for the operational system, IBM Secureway will be used to provide 3"* party failover and 
load balancing capability.] 

To ensure that the user may always access the CIS system, even in the event of a badge or 
authentication system failure, the existing manual user ID/password entry capability must continue to be 
available as a backup and to acconmiodate non-pilot participants. 

During the pilot, two biometric technologies will be available for enrollment and authentication. 
If the user fails to authenticate on one, he should have the capability of using the other. 

The system must be able to accommodate multiple Administration and A&A stations, although 
these may not be implemented during the pilot rollout. 
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5.0 Future requirements 



The following is a list of known/anticipated future system requirements. These will not be 
implemented m the pilot; however, where possible, accommodations iviU be made to allow for such 
upgrades m the future. 

User aliases 
App driven policies 
3"* party failover/load balancing 
Programmed API for data upload/distribution 
Security features - admin logon, mutual authentication, trusted path 
S AF/nt for initial workstation boot/network logon + at physicians desks 
Badge removal detection (now?) 

Audit of who in room at any time, where are all badges presently located 
Badge deactivation/reactivation by user (deactivation now?) 
Auto logoff (when leave room) 
Complex security policies with context and state 
Incorporate user groups 
Periodic DB encryption key changes 
More sophisticated key distribution 
BioAPI compliance 

BSP improvements - indicate which fingers/eyes enrolled, allow update of single template 
More secure channel between badge interface and badge SDK 
Reading/writing of large data blocks to badge, in chunks 
Asynchronous read/write to badge SDK (NT s«vice) 
Use of badge advanced features (speaker/mic, LEDs, etc.) 
Utilize Unix biometric server 
Use open system enterprise database - Oracle 
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I. Introduction and System Overview 



The Wireless Identification and Data Interface (WIDI) system is being 
built for Kaiser Permanenteto provide automatic identification and small-scale 
data transport services. It is understood that the interest of Kaiser Permanente 
is to test the applicability of such a system in a medical/healthcare setting. 
The primary goal of this application is to increase security levels for 
information levels while services, v\^hile easing the operational burden on the 
user by reducing the dependence on use of usernames and passv/ords within 
medical information systems and extending the current ease of use provided by 
conventional magnetic stripe and RFID access control badges into the realm of 
medical information systems. 

The system is targeted to allow physicians and other healthcare 
providers in various locations easy and rapid secure access to medical 
information applications by providing alternative credentials (to the 
conventional username and password) that will identify and authenticate the 
provider. This functionality will simplify centralizing identification and 
authentication records, and will minimize the need for wide spread access to 
such centralized records by providing authentication credentials that travel 
with the provider. By providing the ability to transport small amounts of 
relevant data with the human user, the WIDI system can also simplify working 
situations in the absence of network connectivity. 

The WIDI system is comprised of 3 main elements: 

The first element, which provides the identification, authentication and 
data transport services, is a badge device. The badge has 2 communication 
channels on board, one radio frequency link (RF) that provides long-range 
(room scale), low speed communication, while the other is an infra-red (IR) link 
that provides short-range (few feet), high-speed communication as well as field 
of view (FOV) detection. The badges are equipped with a small amount of 
memory that can be used to transport arbitrary data. In addition, the badge 
includes lights and a small sound beeper to provide feedback to the user and a 
simple sensor to help detect when the badge has been removed. In addition 
the badge contains a holder for a traditional Kaiser- Permanente ID badge, 
which can be used to add an additional level of system security. 

The second element is the base stations, which are the interface 
between the. badges and the computer workstations running the application 
software. The base stations also have RF and IR links to communicate with the 
badges, and they communicate with the workstations through the serial 
communications port on the computer platform. 

The third element is a software SDK, written in the C++ programming 
language, that will be used by the applications that are enabled to use the 
system to communicate with the base station and to access the services 
provided by the system. 
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Each of these subsystems are described in greater detail in the sections 

below. 



II. Scope 

It is the understanding of Tagsense, Inc. that the WIDI system is intended to 
be a part of a larger prototype system that Kaiser Permanente is developing for 
the medical/health care field. This scope of this proposal and the scope of the 
ensuing contract between TagSense and Kaiser Permanente is limited to the 
short term development effort of the relevant prototype hardware and a 
software SDK. Due to the very short time frame of this effort, and the 
development risk involved, the specifications listed in the Statement of Work 
are conservative. 

In this phase of the development effort, it is understood that the primary 
objectives are: 

• to create a prototype that provides the basic technical functionality that 
will enable users to evaluate and to understand the overall concept of the 
intended application 

• to create a prototype that conveys "the look and the feel" of the 
application system concept 

In addition to these objectives, it is understood that there exist longer-term 
objectives which would be relevant and necessary for future product 
development but are not essential for initial testing and evaluation. These 
objectives include: 

• optimizing the battery life of the badges 

• optimizing the small size and weight of the badges and base station 

• optimizing the detection angle and range of the infrared and/or RF 
subsystems 

• optimizing the security countermeasures and encryption level of the system 

• evaluating and ensuring compliance with FCC regulations 

Due to the extremely short development time, it is understood that the 
scope of this contract shall be limited to satisfying and meeting the primary 
objectives listed above. 
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III. statement of Work 

The following sections describe the basic specifications of the system. 

Badge Hardware 
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Badge components 



The role of the WIDI badge is to communicate with the base station, to 

In^Th H '^'t ^ of data (e.g. credentials 

and badge health parameters), and to provide some task-related feedback to 
the user in the form of simple lights and an audible tone. 

TagSense shall provide 30 badges which include the following features: 

• RF communication (9600 baud nominally) 

• RF range can be electronically adjusted over at least 2 settings 

• Infrared communication (>9600 baud) 

• 16 or more Kilobytes of datastorage 

• Real-Time Clock module 

. Support for a "time-to-live" setting vvhich establishes a lifetime for badge 
resident user data. Upon expiration, the badge will self-erase all user data 

• LED and beeper for user feedback 

• At least 16 hours battery life 

• Battery-powered (a variety of battery options will be explored to helo 
minimize size and weight of the badge. 



WIDI 
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• option for tethered reprogrammability/communication via PC 

• There will be a unique number assigned to each badge (digital identifier) 

• Contact sensor to determine if a traditional ID Badge is inserted in the 
badge holder. The badge will have no means of verifying that the object 
placed in the badge holder is indeed an authentic ID badge. 

• limited spoof protection to safeguard against man-in-the-middle and 
playback attacks. 

• Capacitive sensor to be used as a possible means to help determine the 
removal of the badge from a user 

• The ability to notify the base station of state changes in one or more of the 
onboard sensors 



Base Station Hardware 
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WIDI Base Station components 



The base station is the interface between the badges and the rest of the 
system. The base station has four major features IR communication, RF 
communication, user feedback, and interface with the SDK. The basic function 
of the base station is to communicate information to and from the badges 
through IR and RF data links. Additionally, the base station shall detect if a 
given badge is within line of sight (a.k.a. "sight detection"). It is assumed that 
the base station shall be connected to a computer. 

TagSense shall provide 15 base stations that include the following features: 
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• IR Link for the purpose of sight detection and data transfer. Each badge 
may emit an IR refresh signal at some frequency to be specified. Secondly, 
the refresh signal also provides a means by which the line of sight detection 
can be effected. 

• RF link for badge detection and badge identification. Assuming parts 
availability, the operating frequency in the range of 433 MHz shall be used. 
This frequency is a common standard for commercial wireless devices and is 
a good trade-off between high frequency (data rate, bandwidth) and low- 
frequency (RF penetration, resistance to human shielding effects). 

• A discovery algorithm which enables the system to detect new badges which 
enter within RF range of the base station. Although in theory this discovery 
process can be used to enable support for an arbitrary number of badges, in 
practice, the number of badges is limited by user requirements for system 
update rate and limited by certain special cases, such as a number of 
badges entering the RF range simultaneously. 

• The base station will be able to uniquely identify and communicate with at 
least four badges within the RF range. The system will continue to 
communicate reliably with these pre-existing badges if more badges enter 
the area within RF range. 

• The base station will have an electronically tunable range over at least 3 
settings, where one of the settings is no output. 

• The user feedback will be done using LED's and a beeper. The purpose of 
the feedback is to let the user know if a download/upload or login is in 
progress, successful or unsuccessful. Application access to the LED's and 
beeper functions will be exposed throughout the SDK 

• The base station is connected to the computer through the serial port at 
9600 baud or greater. 

• The IR field of view of the base station will be at least 30 degrees to the 
left and right of the center of the base station. 



Software SDK 

The software SDK will provide the means of interaction between the Kaiser 
applications and the system. The SDK will be written as a Windows dynamic 
linked library (DLL) that will provide library calls implementing the various 
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levels of functionality. The most basic level of functionality will be the transfer 
of arbitrary encoded data to and from a device connected to the serial port; 
this data will include both instructions for the base station connected to the 
serial port, and instructions and data for onward transmission to one or more 
badges. The functions provided by the SDK will utilize this functionality to send 
commands and provide the identification, authentication and data transport 
services to the applications that use the SDK. 



• The ability to set up a particular badge (e.g. reset, determine status, write 
user data, set "time to live", etc.). 

• Data management will be done by the badge. Each user data element will 
consist of three parts: data tag identifier, data value, and access password. 
The SDK will support the reading, writing and deletion of individual data 
elements. The SDK will support a "delete all" function protected by a 
global password. It should be noted that this data structure was proposed 
by Kaiser Permanente and it is acceptable by TagSense for the prototype; 
however, in general, it is not good design to transmit passwords, and 
implementing a challenge- response scheme for data access is preferred. 

• Support for event notification: programs should be able to request 
notification of events such as a specific badge entering or leaving either RF 
or IR range of a base station, as well as continuous keep alive signals 
(indicating that a specific badge is still in range of the base station). 

• System enumeration functions, to allow a count to be taken of all the 
badges within RF or IR range of the base station, with a minimum of 5. 
Typically the IR enumeration will be directional and will provide a field-of- 
view (FOV) count that can be used to determine whether or not a badge is 
within line-of-sight to a specific monitor. 

• Ability to detect compromise history of a particular badge. The badges will 
use a sensing technique to provide reference information about whether or 
not a badge has been removed. The SDK will provide functions to let an 
application retrieve and modify this information in real time. 

• Integrated into the device will be limited safeguards against RF and IR 
replay, and man-in-the-middle attacks. A random message sequence ID 
number scheme will be adopted as the limited safeguard against replay 
attacks, and a time-stamp and message request timeout will be adopted as 
the limited safeguard against man-in-the-middle attacks. Protection 
against eavesdropping will not be implemented for the prototype, since the 
only effective defense against eavesdropping is a strong encryption 
algorithm for the RF/IR transmissions, which requires development beyond 
the scope of this contract. 



} 
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• Software will be written in C/C++ 

• It is assumed that the user data received by the SDK /SDK will already be 
encrypted, so no additional encryption will be provided, 

IV. Packaging 

Packaging of the prototype WIDI hardware is critical in order to provide 
ease of use and to enable use of the hardware in a realistic setting. If the 
prototype system is to be evaluated by "real-world" users at some future date 
proper and robust packaging of the badge and base station are necessary, not ' 
merely for aesthetic reasons, but are simply needed to make the system 
usable. 

TagSense shall provide the following packaging features for the badges: 

• robust design 

• attention to minimizing size and weight with maximum size not exceeding 
3.5" X 4.5" X .75" and weighing no more than 5 oz including batteries. 
These numbers are very conservative, but permit a variety of form factors 
and battery options to be explored. 

• attachment method to ensure IR communication and ease of removal 

• Splash -resistant sleeve 

• Accommodation (holder) into which user can insert existing name badge 

• Aesthetically pleasing appearance 

TagSense shall provide the following packaging features for the base 
stations: 

• robust design 

• attachment method to computer monitor which ensures communication 
with badge and ease of use with the goal of being as unobtrusive as 
possible. 

• Splash-resistant casing 

• Minimum-size form factor with aesthetically-pleasing design 
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V. Resources 



Facilities 

TagSense has 300+ sq ft of commercial office space located at 432 Columbia St. 
in Cambridge, MA. This lab contains all the necessary equipment for design, 
testing, and assembly of the electronics hardware. Fabrication of the actual 
printed circuit board shall be done by an external board fab house, which is 
standard practice in the industry. Fabrication of the electronics packaging and 
plastic housing will require some use of external resources such as a laser 
cutter and machine shop which Tagsense shall lease hourly in the local area. 
To save time on the electronics assembly for the multiple circuit boards, 
TagSense will also hire an external assembly service at a rate of $26/ hour to 
assist with the soldering. 

Personnel 

Rich Fletcher (project management, badge hardware): 
A^. Fletcher is currently completing his PhD thesis at the MIT Media Lab wth 
emphasis on low-cost electromagnetic identification and sensing systems. Mr. 
Fletcher holds bachelor degrees in Electrical Engineering and Physics from MIT 
as well as a Master's Degree from the MIT Media Lab. His past experience 
includes research in wireless sensors, short-range wireless electronics, and 
passive microwave devices as an officer in the US Air Forte. 

Kenroy Cayetano (base station hardware): 

Mr. Cayetano is currently a research assistant at the AAcLean Hospital 
Brain Imaging Center. He received the Minor Degree in Mechanical 
Engineering and the S.B degree in Electrical Engineering and Computer Science 
from MIT in 2000 and is currently completing a Masters of Engineering, with 
thesis work on Magnetic Resonance Imaging hardware. His interests and 
research include MRI RF receiver coil design, and analog and digital circuit 
design. 

Steve Gray (Embedded code - firmware): 

Mr. Gray has an S.B. degree from MIT in Electrical Engineering and Computer 
Science and a Master's Degree from the MIT Media Lab. Mr. Gray specializes in 
developing firmware for low-power v/ireless networks, and has worked as a 
consultant on several projects, including telemetry systems for the European 
Motorcycle Grand Prix and the climbing expeditions to Mt. Everest. His most 
recent project is a portable wireless telemetry system for the US Army for 
monitoring the physiological parameters of field soldiers in real time. 
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Olufemi Omojola (Windows software, SDK): 

Mr. Omojola is currently a research assistant in the Physics and Media 
Group at the MIT Media Laboratory, He received the S.B. degree in electrical 
engineering and computer science from MIT in 2000 and is currently completing 
a Masters of Engineering. Mr. Omojola served as a 3-year summer intern at 
Microsoft Corporation developing Windows database systems and software 
packages such as Microsoft BackOffice. His interests include flexible 
reconfigurable hardware architectures for signal processirtg and applications for 
human-computer interfaces. 

Kelly Heaton (industrial design, fabrication): 

Kelly Heaton is a designer with a background in art and science. She received 
her Bachelor's degree in Ecology and Urban Planning from Yale University 
(1994) and her Master of Science from the MIT Media Laboratory (2000). She 
has also conducted post-graduate research at the School of the Museum of Fine 
Arts, Tufts University and the College of Veterinary Medicine at North Carolina 
State University. She has received numerous grants and fellowships for her 
work in visual art, including the prestigious Jacob K. Javits Fellowship. Her 
research at the MIT Media Laboratory has been presented at SIGGRAPH (1999) 
and can be seen on the web at: http://www.media.mit.edu/-kellv . Heaton is a 
current recipient of an individual artist's grant from the MIT Council for the 
Arts and a Research Affiliate of the Center for Advanced Visual Studies at MIT. 
Ate. Heaton has worked on a number of industrial design projects, including 
design and fabrication of prototypes for the toy industry. 



VI. Schedule 

The schedule for this project is six weeks, with system scheduled to ship 
on or before Saturday, November 4, 2000. This is an extremely aggressive 
schedule, given the number of units that need to be produced and hand- 
assembled. 
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VII. Cost Proposal 



The primary factors determining the cost are the following: 

• very aggressive schedule 

• number of units that need to be hand-assembled (30 badges, 1 5 base 
stations) 

• royalty-free license to Kaiser-Permanente for production of future units 
The following is our cost proposal: 



Engineering: 

$65/hr X 25 hrs/week X 6 weeks = $9750/person X 4 people = $39,000 



Packaging design, fabrication, machining: 




$65/hr. X 40 hrs/week X 3 weeks X 1 person = 


$10000 


Electronics assembly service: 




$26/hr X 40hrs = 


$1500 


Printed circuit board fabrication service: 


$10500 


Electronic components and radio modules 


for 30 badges, 15 base stations 


$3000 


Packaging/housing materials/hardware: 


$1500 


Machine shop/laser cutter leased time: 


$3000 


Administrative/lawyer fees: 


$1000 



TOTAL: $69,500 



TagSense requests a deposit/retainer fee of $15,000 to cover initial parts 
procurement and set-up costs, with the balance to be paid in full upon delivery 
of the proposed system. Travel costs will be reimbursed separately by Kaiser 
Permanente and are not part of this contract. 
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VIII. Additional Terms 

TagSense and Kaiser Permanente shall use good faith in including the 
terms of this proposal, and certain additional terms customary for this type of 
arrangement, in the binding agreement. Additional terms are the following: 

Acceptance and Approval: 

To mark completion of the contract, TagSense agrees to deliver 30 badges, 
15 base stations, and a software SDK with specifications meeting or exceeding 
what is specified in this proposal. Payment to TagSense is expected shortly 
thereafter. 

In addition to the deliverables stated above, TagSense agrees to supply 
Kaiser Permanente with the necessary materials and information needed to 
copy the prototype. These materials are: 

• CAD files (gerber format) for the circuit boards for the badge and base 
station 

• Firmware hex files used to program the microcontroller on the badge and 
the base station 

• CAD files and drawings for the badge and base station packaging 

• Bill of materials (i.e. parts list) 

In addition, TagSense also agrees to provide the following: 

• Circuit schematics for the badge and base station 

• Source code for the software SDK 

• Brief (2-3 pages) written instructions describing the use of the badee. base 
station, and SDK. 



The source code for the firmware v^nll not be provided under this contract 
since it is not required for making additional copies of the prototype system 
and since it contains a large amount of pre-existing intellectual property that 
TagSense does not wish to disclose at this time. The firmware hex files are 
sufficient for the purpose of making additional copies of the prototype. 

Parts Availability: 

Due to the short time period of this contract, parts must be procured in a 
timely manner. Tagsense will procure parts as soon as the initial retainer fee is 
received. TagSense has already investigated the ordering availability of the 
parts required for this project as of Sept 13, 2000. However, parts availability 
IS always subject to change. Should a required pari: become unavailable, 
TagSense shall procure an appropriate substitute. If this change will result in 
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any significant change to the system specifications, TagSense will let this be 
known to Kaiser Permanente. 



Post-contract support and warranties: 

In order to meet the needs of Kaiser Permanente for test and evaluation, a 
significant amount of design effort shall be devoted to making the hardware 
physically robust and user-friendly. Nevertheless, it is to be understood that 
system to be developed is a working prototype with its primary goal being to 
demonstrate functionality. 

TagSense will make a best effort to minimize the cost of the badge and to 
maximize its manufacturability. Due to the tight deadline and space 
constraints on the badge, integrated radio modules will be used for this design, 
which cost approximately $15 each in quantities of one thousand. After the 
testing of the system by Kaiser Permanente, it may be possible to replace this 
radio module with a low data rate cheaper discrete parts radio at the expense 
of increased badge size and increased complexity. TagSense will consider a 
follow-on task to further explore design options and to continue development 
of the system. 

For the six-month period following delivery of the system to Kaiser 
Permanente, TagSense agrees to the following included in the cost of the 
contract: 

• Reasonable amount of telephone support for technical questions (for 
example, 2 calls per week or less) 

• Hardware repair. Kaiser Permanente will cover shipping costs. Units that 
have been abused or physically damaged by users are not covered. 

Following the six month period, TagSense will consider a service agreement 
with Kaiser Permanente to continue repair/maintenance of hardware. 

Intellectual Property: 

Upon completion of the contract, TagSense shall retain the right to all pre- 
existing intellectual property (e.g. wireless hardware, firmware, electronics 
know-how) used in this project. TagSense reserves the right to continue using 
such intellectual property, with the exception of application-specific 
Intellectual properiiy covered under the Non-Disclosure Agreement between 
TagSense and Kaiser Permanente. TagSense will retain full rights to the design 
created under this contract until final payment is received from Kaiser 
Permanente. Upon completion of the contract and receipt of payment. Kaiser 
Permanente shall be granted non-exclusive non-transferable royalty-free rights 
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to the specific hardware and software developed under this project for sole use 
in the intended application discussed for this project. 



LiabUity: 

TagSense has no knowledge of and makes no claims regarding the usability or 
suitability of this hardware for this application. TagSense is developing this 
hardware to match the specifications set forth by Kaiser Permanente and shall 
not be liable for any potential future legal claims set forth against TagSense or 
against the systems developed under this contract. 



WIDI: Wireless Identification and Data Interface System, ©2000 TagSense, Inc. 
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SuggestedAPI.txt 



Example API for Kaiser Badge 



Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 

Result 



GetAPIVersionO ; 
GetBadgeVersionO ; 

ResetTheBadgeCBadgeNumber TimeToWait) ; 
SeteadgeAccessPasswordCBadgeNumber, Password) • 
InxtializeTheBadgeCBadgeNumber, Password)- 
= SetExpirationTime(BadgeNuiTiber, Password, ExpirationTime) • 
= GetExpirationTime(BadgeNuinber, Password) - "^^^^^^^^^^^^^ ' 
- SetBadgeRFPower(BadgeNumber, Password, Power)- 
= GetBadgeRFPower(BadgeNuinber, Password)- 
= SetBaseRFPower (Power) ; ' 
= GetBaseRFPower () ; 

= SetBadgeIRPower(BadgeNumber, Password Power)- 
= GetBadgeIRPower{BadgeNumber, Password)- 
= SetBaselRPower (Power) ; 
= GetBaselRPower 0 ; 

= SetBadgeStatus (BadgelD, Password, Status); 

GetBadgeStatus {BadgelD, Password) ; 
= GetBadgesInView{BadgeList) ; 



!'^Saia/Lengthtr^^''^^^^*^''^'°' Dataldentif ier, DataPassword 

d^^Dijl;\engS^?"^^'^^^^^^''''^'''' Dataldentif ier, DataPasswor 

alswordi; °®^®^^°^^^^^°"*^^9f«(B^'isreID, Password, Dataldentif ier, DataP 
Result := Dele teAllData (BadgelD, Password); 

:= SetSystemTimejBadgelD, Password, Hours, Minutes, Seconds); 
= GetSystemTime (BadgelD, Password, Hours, Minutes, Seconds!; 



Result 
Result 

Result 
Result 
Result 

Result 
Result 
Result 



= SetBadgeLEDs (BadgelD, Password, LEDMASK) ; 
= GetBadgeLEDs(Ba:dgeID, Password, LEDMASK)- 
= SoundBadgeBeep (BadgelD, Password, FrequeAcy, Duration); 

= SetBaseLEDs (BadgelD, Password, LEDMASK); 
= GetBaseLEDs (BadgelD, Password, LEDMASK) ; 
= SoundBaseBeep (BadgelD, Password, Frequency, Duration); 



long SetVisibleTimeout (long VisibleTimeout) • 

long GetVisibleTimeoutO; 

long SetLostBadgeTimeout (BadgelD ID, 

long Lost_Timeout, 
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SuggestedAPI.txt 
long MaxDelay, 

long GetI^seBadgeTimeout(BldgeJD'?^ 

long MaxDelay, 
void *GlobalPassword) ; 
long GetEnumerationSizeO • 

long GetEnumerateBadges (pEnumeratedBadges pBadges 

long Size, 
long *ActualSize) ; 



long DataItemAsyncWrite(BadgeID ID, 

long Tag, 
long Length, 
void *data, 
long MaxDelay, 
void *Password 

gs TBD //. // the followin 

//CallBackFunction, 
//... 

) ; 

long DataItemGetSize(BadgeID ID, 

long Tag, 
long MaxDelay, 
void *Password) ; 



long DataItemAsyncRead(BadgeID ID, . ' 

long Tag, 
long Size, 
void *Data, 
long *ActualSize, 
long MaxDelay, 
char * Password 

//CallBackFunction, " f^^o^ing TBD 

//... 

) ; 

long DataltemsGetNumber (BadgelD ID, 

long MaxDelay, 

void *GlobalPassword) ; 

Page 2 



Suggest edAPI . txt 



long DataltemsEnumerate (BadgelD ID, 

long Size, 
long *Tags, 
long *ActualSize, 
long MaxDelay, 
void *GlobalPassword) 
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EXHIBIT E 



"BARB Test Announcement" Prod. #5951* 5/23/01 • 



FADE IN: 

1 . OPEN WITH SEVERAL VERY 
CLOSE SHOTS OF THE BARB. 
WITH EACH SHOT, WE REVEAL 
MORE AND MORE 



2. WE NOW SEE A SHOT OF BARB 
FULLY REVEALED (IT COULD BE 
HELD IN SOMEONE'S HAND. THEY 
FLIP IT BACK AND FORTH SO WE 
SEE BOTH SIDES, INCLUDING ALL 
THE ELECTRONICS) 

3-6. OMIT 



7. TRANSITION TO CLOSE SHOT OF 
THE BARB, NOW ATTACHED TO A 
PHYSICIAN'S ID CARD. THEN CUT 
TO OVER-THE-SHOULDER SHOT 
OF A PHYSICIAN AT A COMPUTER 
TERMINAL 

7A. START THIS SEQUENCE WITH A 
CLOSE UP OF THE BARB, THEN 
CUT TO SCREEN SHOTS AS THE . 
CIS LOG-ON PAGE APPEARS 
(WITH USER ID AND PASSWORD 
ENTERED); CIS MAIN MENU 
APPEARS 



8. TRANSITION TO BARB 

•ENROLLMENT' AREA - SHOW 
BRIEF SEQUENCE OF EVENTS AS 
OUR "PHYSICIAN" IS BEING 
MEASURED FOR FINGER AND/OR 
IRIS SCAN 



VOICE OVER NARRATOR: It measures about 3 by 4 
inches. It weighs just an ounce and a half. It's so light you 
barely know it's there. 

It's called the BARB and it's going to make your life a lot 
easier. 

/ 

The BARB is a small electronic device used in conjunction 
with Kaiser Pernnanente's new Clinical Information System 
" or CIS. 

BARB enables you to access CIS without having to use a 
password every time you log on. Kaiser Permanente is 
currently testing the BARB prototype and here's how it 
works. 

During a one-time enrollment process, we'll scan your 
finger or take a picture of your eye. These measurements 
are unique to you and some of the characteristics are 
stored to be used to verify your identity. 
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BARB 'PICK UP' AREA - START 
WITH CLOSE SHOT ON A BOX OF 
BARBS. PULL OUT AS OUR 
PHYSICIAN ENTERS THE AREA, 
PICKS UP A BARB AND SLIPS IT ON 
HIS EMPLOYEE ID SHOOT WITH 
ASSIGNED BARB TOO 



10. ANOTHER ANGLE AS OUR 

PHYSICIAN GOES TO COMPUTER 
TERMINAL TO SIGN-IN. SHOW 
SCREEN THAT REQUESTS ENTRY 
OF THE BARB/BADGE NUMBER 

10A. CLOSE SHOT OF BARB BADGE AS 
PHYSICIAN TURNS IT OVER TO 
SEE ID NUMBER 

10B. CLOSE SHOT OF COMPUTER 

SCREEN AS PHYSICIAN ENTERS 
BADGE NUMBER 

IOC. REMAIN CLOSE ON COMPUTER 
SCREEN AS PHYSICIAN ENTERS 
USER ID AND PASSWORD 

10D. REMAIN CLOSE ON SCREEN AS 
WE SEE "PLEASE PLACE YOUR 
FINGER ON THE FINGER LOCK 
SENSOR." INCLUDE SHOT OF 
PHYSICIAN PLACING FINGER ON 
THE SENSOR 

10E. ALSO SHOW SEQUENCE ON THE 
SCREEN IN WHICH WE SEE A 
REQUEST FOR "IRIS 
RECOGNITION" AND THE 
PHYSICIAN TAKING AN IRIS SCAN 

10F. SHOT OF "ACTIVATION 

SUCCESSFUL" SCREEN (WITH 
EXPIRATION TIME) 



Then, every time you come to work, you'll pick up a BARB 
in a designated area and attach it to your ID card. At this 
point, the BARB is blank, with no data linking it to you or 
anyone else. 

Next, during a brief computerized sign-in procedure, you'll 
be prompted to enter your BARB's ID number. 

You'll find it on the back of your BARB badge. 



You'll also be asked to enter your user ID and password. 

Then we'll either scan your finger and compare the results 
to the data taken earlier and stored in the system... 



..or we'll use iris recognition to verify your identity. 



® 



Once that's done, the BARB you're wearing is automatically 
activated and will remain active until the expiration time 
shown on the screen. 
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10G. ANGLE AS OUR PHYSICIAN 

LEAVES THE SIGN-IN AREA AND 
HEADS FOR HIS/HER OFFICE 



11. MOVED AFTER 15A 



That's all you have to do. Everything else happens behind 
the scenes. 



12. INT - PHYSICIAN'S OFFICE. ANGLE 
AS THE PHYSICIAN ENTERS THE 
OFFICE AND SITS AT HIS/HER 
COMPUTER. WE SEE THE BASE 
STATION 

12A. START WITH SHOTS OF LIGHTS 
BLINKING ON THE BASE STATION. 
ALSO CLOSE SHOTS OF THE 
BARB. THEN SCREEN SHOTS OF 
THE CIS LOG-ON SCREEN BEING 
OPENED. WE SEE USER ID AND 
PASSWORD, THEN CIS MAIN MENU 
APPEARS 



12B. SHOW PHONE MESSAGES 
SCREEN 

12C. SHOW PATIENT INFORMATION 
SCREEN 

12D. CLOSE SHOT OF THE PHYSICIAN 
HITTING F3 ON THE KEYBOARD. 
THE PROGRAM LOGS OFF. 
PHYSICIAN LEAVES HIS/HER 
OFFICE 



13. INT - EXAM ROOM. PHYSICIAN 
ENTERS THE EXAM ROOM, 
GREETS PATIENT SITTING ON 
EXAM TABLE AND APPROACHES 
COMPUTER TERMINAL 



Now, when you go to your office or an exam room, you'll 
see a small base station next to the computer terminal. 

The station detects your BARB, notifies the system that 
you're in the area and automatically opens the CIS log-on 
screen. The system automatically enters your user ID and 



passwordTThen goes to the CIS Main Menu. You (fan open 
many menu items without having to enter a separate 
password for each one. 

For example, you can retrieve your phone messages. 
Or you can call up patient information. 

(i> 

When you leave your office, it's easy to log off so an 
unauthorized person can't change or see any confidential 
information. 

In each exam room you enter throughout the day, BARB 
makes logging on to CIS just as quick and easy. 
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13A. CLOSE SHOT ON COMPUTER AS 
CIS LOG-ON SCREEN APPEARS 
ALONG WITH USER ID AND 
PASSWORD. CIS MAIN MENU 
APPEARS 



13B. SCREENS SHOWING PATIENT 

INFORMATION AND LIST OF MEDS 
SCREEN 



1 4. CLOSE SHOT OF THE PHYSICIAN 
HITTING F3 ON THE KEYBOARD. 
THE PROGRAM LOGS OFF. (WE 
SEE THE PATIENT LEFT ALONE IN 
THE EXAM ROOM. THE PATIENT 
REMAINS SEATED ON THE EXAM 
TABLE. BUT WE SEE HIM/HER 
TRYING TO SEE WHAT'S ON THE 
COMPUTER SCREEN) 

14A. INT - SAME EXAM ROOM, LATER. 
MEDIUM SHOT IN SAME EXAM 
ROOM WITH A DIFFERENT 
PHYSICIAN (WEARING A BARB) 
AND PATIENT. PHYSICIAN 
APPROACHES THE SCREEN. 
SCREEN SHOTS AS WE SEE THE 
CIS LOG-ON SCREEN WITH THE 
USER ID AND PASSWORD 
ALREADY FILLED IN. THEN CIS 
MAIN MENU APPEARS 



Simply approach the computer and the CIS log-on screen 
appears. Each time, your user ID and password are 
automatically entered with no action on your part. 

Once you're in CIS, you can access patient information or a 
list of medications your patient is taking without having to 
enter a separate password. 

After you're finished using the computer, a single key 
stroke logs you off. 



Later, when another physician uses the same exam room, 
his or her BARB will also automatically open the CIS log-on 
screen and enter the user's ID and password. With BARB, 
it's that easy to call up CIS time after time...user after user. 
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14B. SEVERAL OTHER QUICK SHOTS OF 
SEVERAL PHYSICIANS ENTERING 
VARIOUS EXAM ROOMS AND THE 
CIS LOG-ON SCREEN 
AUTOMATICALLY BEING PULLED 
UP TIME AFTER TIME 



14C. SCREEN SHOT OF THE CIS LOG-ON 
SCREEN WITH USER ID AND 
PASSWORD FILLED IN 

14D. SHOT OF PHYSICIAN AT 

COMPUTER ACCESSING CIS 
PROGRAMS. WE SEE THE PATIENT 
TRYING TO SEE WHAT THE 
PHYSICIAN IS DOING AT THE 
COMPUTER 

15. SCREEN SHOT OF A PATIENT 
RECORD OR MEDICATION LIST 



15A. PHYSICIAN HITS F3 AND PROGRAM 
LOGS OFF 

1 1 . BARB 'ENROLLMENT' AREA - OUR 
PHYSICIAN ENTERS AREA, 
REMOVES HIS BARB AND PLACES 
IT BACK IN THE BOX. HE LEAVES 
THE AREA SHOOT WITH 
ASSIGNED BARB TOO 

FADE OUT 



When you think of all the times you and your colleagues will 
be accessing the Clinical Information System during the 
day, BARB is definitely a convenience and a time saver. 
Without BARB, you'd have to type in your user ID and 
password every time you entered a new exam room or 
office and logged onto CIS. 

Instead, BARB recognizes you and signs you in. 

And because there's no password to enter in the exam 
room, patients can't learn your password simply by. 
watching you enter it. 

BARB also allows only authorized personnel to log onto 
CIS, giving our patients the assurance that their health 
information is private and secure. 



At the end of the day, simply return your BARB and it will 
deactivate. 



We've developed BARB to make your life easier - we hope 
it does. 
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